Object-Oriented Programming

with Java
Introduction

Quan Thanh Tho, Ph.D.

CSE – HCMUT
[email protected]
1
Contents
lObject-Orientation
lObjects and Classes
lOverloading
lInheritance
lPolymorphism
lGeneric Programming
lException Handling
lIntroduction to Design Patterns
2
Outline

§ Java
§ First Program in Java
§ OOP

3
What Is Java?
lHistory
lCharacteristics of Java

4
History
lJames Gosling
lOak
lJava, May 20, 1995, Sun World
lHotJava
¡The first Java-enabled Web browser

5
Characteristics of Java
l Java is simple
l Java is object-oriented
l Java is distributed
l Java is interpreted
l Java is robust
l Java is secure
l Java is architecture-neutral
l Java is portable
l Java’s performance
l Java is multithreaded
l Java is dynamic

6
JDK Versions
l JDK 1.02 (1995)
l JDK 1.1 (1996)
l Java 2 SDK v 1.2 (a.k.a JDK 1.2, 1998)
l Java 2 SDK v 1.3 (a.k.a JDK 1.2, 2000)

7
Java IDE Tools
l Inprise JBuilder
l Microsoft Visual J++
l Symantec Café
l Forte by Sun MicroSystems
l IBM Visual Age for Java

8
Getting Started with Java
Programming
l A Simple Java Application
l Compiling Programs
l Executing Applications
l A Simple Java Applet
l Viewing Java Applets
l Applications vs. Applets
9
 A Simple Application
Example 1.1
//This application program prints Welcome
//to Java!
public class Welcome
{
public static void main(String[] args)
{
System.out.println("Welcome to Java!");
}
}

Source Run
10
Compiling Programs
lOn command line
¡javac file.java

Java Source
File

Compiler

Bytecode

11
Executing Applications
lOn command line
¡java classname

Bytecode

Java Java Java

Interpreter Interpreter Interpreter
...
on Windows on Linux on Sun Solaris

12
Example
javac Welcome.java

java Welcome

output:...

13
Object-oriented Programming
A brief introduction

14
Challenges of Software Development

• Complexity:
• Longevity and Evolution
• High User Expectations

15
1) Complexity
• The software systems are very large and complex.
•No individual can comprehend every detail of the
system.
•The system must be broken down into manageable
parts.
•Methodologies, techniques, and tools that work
well for small systems developed by individuals
are not effective for large systems developed by
teams.
16
2) Longevity and Evolution
• Because of economic, political, and other
constraints,
software systems are often in service for very
long periods of time.
• During their lifetimes, software must
constantly evolve to accommodate changes in
users’ needs and environments.
• Making changes to software systems is a
difficult task. 17
2) Longevity and Evolution
• Furthermore, maintenance not only is costly
and time-consuming, but also usually degrades
the quality of the system being maintained.
• The maintenance cost of the software system
over its lifetime is far greater than its initial
development cost.

18
3) High User Expectations
• Inthe past: Computers were mainly used in
universities, research institutions, and large
corporations.
The majority of software systems users were
engineers and scientists, who had the technical
skills to handle the glitches they might
encounter while using the system.
•

19
3) High User Expectations
• Today: Computers are used in homes, schools,
and business of all sizes, and are used for pleasure
as well as for work.
Majority of software users are nontechnical,
ordinary people.
Computer software products are considered as
consumer products. The products are expected to
perform as household appliance. Software systems
are expected to be “bug-free”,
but such perfection is next to impossible. 20
 Challenges of Software Development
The challenges faced by software development
are:
• to find effective solution to control complexities
of software systems;
• to manage the longevity and evolution of
software systems;
• to deliver software systems with higher
reliability and usability.

21
Two Paradigms of Programming

l Program = Code + Data

Program can be organized around Data or around
Code
l Two paradigms of programming:
1) Process-oriented model: around Code (acting on
data)
Program is defined by sequence of codes
Data structures + Algorithms = Program
Problem complexity: <25,000-100.000 lines of
code
2) Object-oriented model: around Data (Objects)
Objects + Messages = Program
22

Data-controlling access to code

OOP five rules of Alan Kay
lEverything is an object.
lA program is a bunch of objects telling
each other what to do by sending
messages.
lEach object has its own memory made
up of other objects.
lEvery object has a type (class).
lAll objects of a particular type (class)
can receive the same messages. 23
Class
l A class defines the abstract characteristics of
a thing (object), including the thing's
characteristics (its attributes) and the thing's
behaviors (the things it can do or methods).
l For example, the class Dog would consist of
traits shared by all dogs, such as breed and
fur color (characteristics), and the ability to
bark (behavior).
l Classes provide modularity and structure in
an object-oriented program. 24
Objects
lOOP model is to work in the problem
space
lObjects can be described in terms of:
¡Their attributes;
¡Their behaviors
lObject’s attributes and behaviors are
encapsulated together a data type (class).
lObjects are independent entities.
lObjects respond to messages.
25
Message passing
lMessage passing is the process by which
an object sends data to another object or
asks the other object to invoke a method.
lAlso known to some programming
languages as interfacing.

26
Objects Interfaces
l An object has to have an interface.
l The interface will
¡Provide a way to let other objects to
communicate with it.
¡Hide the details of the object implementation.
l An example: Light bulb and Car.

Light
On()
Off()
Brighten()
Dim()
27
Class Dog and Object Lassie
l Object is a particular instance of a class.
l The class of Dog defines all possible dogs by
listing the characteristics (data, states) and
behaviors (methods) they can have.
l The object Lassie is one particular dog, with
particular versions of the characteristics. A
Dog has fur, Lassie has brown-and-white fur.
l In programmer jargon, the object Lassie is an
instance of the Dog class.

28
Methods
lAn object's abilities. Lassie, being a Dog,
has the ability to bark. So bark() is one
of Lassie's methods. She may have
other methods as well, for example sit()
or eat().
lWithin the program, using a method
should only affect one particular object;
all Dogs can bark, but you need one
particular dog, Lassie, to do the barking.
29
Three Principles of OOP (PIE)
lEncapsulation
lInheritance
lPolymorphism

30
1) Encapsulation principle
l Encapsulation is a process of binding or wrapping the
data and the codes that operates on the data into a
single entity.
l Binding data and functionality (methods) together
produces self contained units which are more
maintainable, reusable and deployable.
l Implementation hiding: encapsulation is as a protective
wrapper that prevents data from being arbitrarily
accessed by other code defined outside the wrapper.
l The collective term for data and operations (methods)
bundled together with access restrictions is a class.
31
1) Encapsulation principle
l For a programming unit to be truly effective, the
barrier between interface and implementation
must be absolute.
l Breaks up the playing field into:
lClass creators (those who create new data
types)
lClient programmers (those who use these types
for their own tasks. They only deal with the
interfaces.)
lThe goal of the class creator is to build a class
that exposes only what’s necessary to the
client programmer and keeps everything else
hidden.
32
1) Encapsulation principle

lTwo reasons for controlling the

access:
* To keep client programmers’
hands off portions they shouldn’t touch.
* To allow the library designer to
change the internal workings of the class
without worrying about how it will affect
the client programmer.

33
2) Inheritance principle
l Inheritance involves building upon an existing class
so that additional or more-specialised functionality is
added.
l Subclasses are more specialized versions of a class,
which inherit attributes and behaviors from their
superclasses,
and can introduce their own.
l Inheritance should be used to capture hierarchical
relationships integral to the problem being modelled.

34
 2) Inheritance principle
l Object-oriented programming languages permit
you to base a new class definition on a class
already defined.
l The base class is called a superclass; the new
class is its subclass.
l The subclass definition specifies only how it
differs from the superclass; everything else is
taken to be the same.
l Nothing is copied from superclass to subclass.
Instead, the two classes are connected so that the
subclass inherits all the methods and instance
variables of its superclass. 35
 3) Inheritance principle
l For example, the class Dog might have sub-classes called
Collie, Chihuahua, and GoldenRetriever. In this case, Lassie
would be an instance of the Collie subclass.
l Suppose the Dog class defines a method called bark() and
a property called furColor. Each of its sub-classes (Collie,
Chihuahua, and GoldenRetriever) will inherit these
members, the programmer only needs to write the code for
them once.
l In fact, inheritance is an "is-a" relationship: Lassie is a
Collie.
A Collie is a Dog. Thus, Lassie inherits the members of
both Collies and Dogs.
36
 3) Polymorphism principle
l The word originates from the Greek language, and
means ‘many shapes’.
l Within object oriented languages it is used to denote
one name referring to several different methods
l Polymorphism allows you to make the derived types
behave differently from their base type.

Bird
Move()

Goose Penguin
Move() Move()
37
 3) Polymorphism principle
l This ability of different objects to respond, each in its own
way, to identical messages is called polymorphism.
l The main benefit of polymorphism is that it simplifies the
programming interface. It permits conventions to be
established that can be reused in class after class.
l Instead of inventing a new name for each new function
you add to a program, the same names can be reused.
The programming interface can be described as a set of
abstract behaviors, quite apart from the classes that
implement them, receive messages from them, and
perhaps make the different objects composing the class
interact with each other.

38