Object-Oriented Programming
Concepts
Four important concepts make up the
Object-Oriented Programming paradigm:
1. Object-oriented programs are made
up from collections of Objects.
2. These objects communicate with one
another in order to perform the program’s tasks. This communication is
by way of Messages.
3. Objects are defined by templates
(type-specifiers) called Classes.
4. Classes can Inherit part of their
behaviour from “ancestor” classes
(SuperClasses).
Objects
The real world is made up of objects:
students, aeroplanes, rocks, lecturers,
etc.
These all have “state” and they all have
“behaviour.”
A Software Object is a transference of
this idea to programming:
A Software Object (or simply Object) is
a software bundle of variables (the state)
and related methods (the behaviour).
A Method is simply a function or procedure that belongs to a software object.
(The term method is very common in OOP.)
Public
API
private
methods
and variables
Private
Implementation
Details
The user of the object can only access it
via its public Application Programming
Interface (API). The public methods
(and sometimes variables) of the API
are allowed to change the internal state
of the object.
The user cannot change the internal
state of the object directly.
“Data Hiding”/“Encapsulation”.
ou
C
t
se
currentCount
countDir
ap
ply
Cl
oc
k
clearCounter
n
o
i
t
ec
r
i
ntD
A “Counter” object. Models a digital up/down
counter.
•
2 hidden pieces of state:
“currentCount”, “countDir”.
•
3 publicly accessible methods making
up the API: “setCountDirection”,
“clearCounter”, “applyClock”.
Once the API is defined, you have freedom to
change the internal implementation at any time.
The API is the “contract” between the object
designer and the object user.
withdrawCash
depositCash
currentBalance
calcInterest
A “BankBalance” object. Models a bank balance.
•
1 hidden piece of state:
“currentBalance”, the amount in the
account.
•
1 hidden method: “calcInterest” .
•
2 publicly accessible methods making
up the API: “depositCash”,
“withdrawCash”.
The user can only modify the balance via the
two publicly accessible methods. These will
have checks to prevent withdrawals from an
empty account, etc.
The Benefits of Objects
Encapsulating related variables and
methods into a neat software bundle is a
simple yet powerful idea with two major
benefits:
1. Modularity: The source code for an
object can be written and maintained
independently from the source code
for other objects. Also, an object can
be easily passed around the system.
2. Information Hiding: An object has
a public interface (API) that other
objects can use to communicate with
it. However, the object can maintain
private information and methods that
can be changed at any time without
affecting the other objects that
depend on it.
Messages
Software objects interact and communicate by sending messages to each other.
If object A wants object B to perform
one of its methods, it sends a message to
B requesting that behaviour.
Message
Object A
Object B
Sometimes the receiving object needs
more information so that it knows
exactly what to do.
This information is passed along with
the message as a parameter to a method.
Message: depositCash(400)
Object A
My “BankBalance” Object
A message is made up from three parts:
1. The name of the object to which the
message is addressed,
(My “BankBalance” Object),
2. The name of the method to perform,
(depositCash),
3. Any parameters needed, (e.g., 400).
Classes
A program usually needs many objects
of the same sort. A banking program
may have many BankBalance objects
which represent different customers, but
which all share the same pattern of
methods and variables.
We say that each unique BankBalance
object is an Instance of the Class of
BankBalance objects.
Every such object is independent of
every other, but they all share the same
layout.
We capture the commonality by defining a blueprint or template for all
objects of the same sort. This blueprint
is a Class Definition.
A Class is a blueprint, (template, prototype), that defines the methods and variables common to all objects of a certain
kind
Note that a class is not itself an object
(usually!). In order to make a new userdefined object you must perform two
steps:
1. Write a class definition for the
object, setting out its variables and
methods,
2. Instantiate the class to create an
object (which is an instance of the
class). You may instantiate a class as
often as you like to create new
objects of the same type.
Every new instance of the class will get
its own set of instance variables.
All objects instantiated from the same
class will share the instance methods of
the class.
Classes may also define Class Variables
and Class Methods.
1. A Class Variable is one which is
shared amongst all instances of the
class.
A class variable may be used, for example,
to represent the standard output stream of
an application. Since a program has only a
single standard output stream, this is a good
use for such a variable.
In the “Hello World” application “out” is a
class variable representing the standard
output stream. It belongs to class “System”
and has method “println” (inter alia).
2. A Class Method is one which may be
called even if no instance of its class
has been created.
The “main” method in the “Hello World”
application is an example of a class
method. No instance of the class
“HelloWorld” is created by this application.
class method “main” of
class “HelloWorld”
HelloWorld.java
public class HelloWorld {
public static void main(String args[]) {
System.out.println("Hello World");
}
}
class variable “out” of
class “System”
Class Diagrams
currentBalance
calcInterest
depositCash
withdrawCash
1. “Doughnut Diagrams,”
Note: no
shading, hence
class diagram
2. Object Modeling Technique (OMT)
diagrams,
BankBalance
public withdrawCash(amount)
public depositCash(amount)
private calcInterest()
private currentBalance
3. Unified Modeling Language (UML)
diagrams.
BankBalance
−currentBalance : integer
+withdrawCash(amount : integer)
+depositCash(amount : integer)
−calcInterest()
Inheritance
In Object-Oriented Programming
(OOP), classes may be defined in terms
of other classes. They may Inherit the
attributes of other classes and specialise
them as needed.
“Matrix” Class
Class
Hierarchy
Diagram
“RotationMatrix”
Class
Superclass
“TranslationMatrix”
Class
Subclasses
“ScalingMatrix”
Class
Each subclass inherits state (in the form
of variable declarations) from its superclass. Hence RotationMatrices, TranslationMatrices and ScalingMatrices all get
a copy of the variables of class Matrix.
Each subclass also inherits all the methods of its superclass. Hence, any methods defined for Matrix are automatically
available to all its subclasses.
Subclasses get the variables and methods of their superclass “for free”. However, they can specialise their behaviour
by adding new methods and/or variables.
They can also override inherited methods and provide specialised behaviour
for these methods. The subclass implementation replaces the superclass implementation with the same name.
The Benefits of Inheritance
1. Subclasses provide specialised
behaviours from the basis of common elements provided by the superclass.
Using inheritance, programmers
can reuse the code in the superclass
many times.
2. Programmers can implement superclasses called Abstract Classes. An
abstract class defines “generic
behaviours.”
An abstract superclass defines, and
may partially implement, the behaviour, but much of the class is undefined and unimplemented. Other
programmers fill in the details with
specialised subclasses.