Object Oriented Programming

(CMM504)

Lecture#1
Object-Oriented Programming
Concepts

© The Robert Gordon University

 Content
 Object-Oriented Programming
Concepts
 components of an object
 class-level vs object-level

 Main features of Object-Oriented

Programming

© The Robert Gordon University K. Hui 2008-2009 2

 Object-Oriented Programming
Concepts
 OOP models the world as a collection of
objects
 e.g. you, your classmates, your dog, your mobile
phone
 objects may relate to/interact with each
others
 e.g. you have a dog, you make a call with your
mobile, you talk to your classmates
 interaction does something
 change of state, side-effect of interaction (e.g.
display on screen, file operation), etc.

© The Robert Gordon University K. Hui 2008-2009 3

 How to Program in the OO
Way?
 Model your world (i.e. problem domain)
as objects
 What objects do you needed?
 How are these objects related to each
other? (i.e. relationships among them)
 Do these relationships make sense?
 How do these objects interact to achieve
what you want?

© The Robert Gordon University K. Hui 2008-2009 4

 The Concept of Object
 a self-contained entity
 has 2 components: attributes & methods
 attributes are also called instance variables
 may or may not be visible to the outside world
(i.e. other objects)
 i.e. can be hidden
 interaction with other objects is controlled/
confined by its “interface”

© The Robert Gordon University K. Hui 2008-2009 5

 Attribute & Method
 attributes
 the data component of an object
 define the descriptive characteristics of an object
 e.g. your dog is brown in colour, your mobile is branded “Nokia”
 methods
 the procedural component of an object
 define the behaviour of an object
 e.g. a dog walks, a mobile sends SMS
 an attribute/method must belong to
something (setting its context)
 you will not find an attribute/method that belongs to nobody

© The Robert Gordon University K. Hui 2008-2009 6

 Interface of an Object
 an object can hide its internal components fro
m the outside world
 why hiding?
 the set of visible components defines the obje
ct's interface to the outside world
 an object's interface defines how it can inter
act with others
 NOTE: some time later, you will see the term "in
terface" in Java, which is NOT the same thing

© The Robert Gordon University K. Hui 2008-2009 7

 Calling vs Invoking a Method
 in OOP, you don’t really “call” a method
 for A to invoke a method in B:
 A sends a message to B, asking B to invoke a met
hod
 e.g. you ask your dog to give you its paw
 B receives the message and decides how to respo
nd
 invoking the appropriate method
 e.g. your dog and cat may give different responses to th
e same request

© The Robert Gordon University K. Hui 2008-2009 8

 How to Program in OOP?
 in short:
 creating some objects
 let these objects interact (via their interfaces) to achie
ve something
 change of states (via attributes)
 effect of behaviours (via methods)
 the question (assume we know what objects we
need):
 How do we create these objects? (i.e the mechanism)
 answer: we create objects from classes

© The Robert Gordon University K. Hui 2008-2009 9

 The Concept of Class
 a template for creating objects
 e.g. the “dog” class defines the attributes
& methods of a dog, but the “dog” class is
NOT an object.
 an object is created from a class
 an instance of a class
 e.g. you are an instance of the “student”
class, your dog is an instance of the “dog”
class

© The Robert Gordon University K. Hui 2008-2009 10

 Objects & Classes
 objects of the same class
 have the same set of attributes & methods
 e.g. each student has a “student no.” attribute,
each dog has a “colour” attribute
 may have different attribute values
 each object has its own copy of the attribute
 e.g. different students may have different
"student no." values, different dogs may have
different "colour" values

© The Robert Gordon University K. Hui 2008-2009 11

 How to Program in OOP?
(Revisited)
 design classes to model the problem domain
 including attributes & methods
 define “interface” to the outside world (i.e. other o
bjects)
 create objects from classes
 make objects to relate/interact
 by passing messages, which invoke methods
 by accessing attributes, via an object’s “interface”

© The Robert Gordon University K. Hui 2008-2009 12

 A Graphical Representation of
Classes

the Dog class

the Person class
attributes
(data specie
name component) colour
own name
interface
where
walk to the
instruct outside world walk
write_email swim
bark
methods
(procedural
component)

© The Robert Gordon University K. Hui 2008-2009 13

 A Graphical Representation of
Objects
Odie, a Dog object

Peter, a Person object Lassie, a Dog object specie: xxx

colour: yellow
name: Odie
specie: shepherd where: xxx
name: Peter
colour: white/brown walk
own: Lassie
name: Lassie swim
bark
walk where: Shetland
instruct
walk …, another Dog object
write_email
swim
bark
Mary, a Person object

name: Mary …, another Person object …, another Dog object

own: null
walk
instruct
write_email

© The Robert Gordon University K. Hui 2008-2009 14

 The Context of Attributes & M
ethods
 an attribute/ method must be attached/
belong to “something”
 its context
 when you refer to an attribute/met
hod, you must specify its context
 whose attribute/method is it?
 e.g. Lassie’s colour, tell Peter to write an email

© The Robert Gordon University K. Hui 2008-2009 15

 Class-level vs Object-level
Context
 attribute/ method can be defined at the class-
level or object-level (i.e. instance-level)
 e.g. the “bank account” class may have a class-
level attribute “interest rate” which is shared by all
“bank account” objects
 each object has its own local copy of an
object-level attribute
 a class-level attribute is shared by all
objects of that class, only 1 single copy

© The Robert Gordon University K. Hui 2008-2009 16

 When to Make it Object/Class
Level?
 object/instance-level attribute:
 if you want each object to have its own copy of th
e attribute (i.e. not shared)
 e.g. each dog object has its own copy of the “col
our” attribute (probably of different value)
 class-level attribute
 if you want all objects of the same class to share t
he same copy of the attribute
 e.g. The Dog class has a class-level attribute “def
ault_num_of_legs” which is shared by all dog
objects.

© The Robert Gordon University K. Hui 2008-2009 17

 Object-level vs Class-level Met
hod
 object-level method:
 when it makes sense that the behaviour should oc
cur in individual objects
 e.g. deposit of money into a bank account
 you must specify which bank account to deposit, not to a
ll objects in the same class!
 class-level method:
 usually as utility methods
 e.g. the String class has a method parseInt
(…) that converts a string into an int value

© The Robert Gordon University K. Hui 2008-2009 18

 How to Program in OOP? (Re-
Revisited)
 design classes
 design their internals & “interfaces”
 take other people’s classes
 know their “interfaces”
 i.e. what are visible to the outside world
 create objects
 let objects interact via their “interfaces”
 i.e. visible attributes/methods
 achieve some tasks

© The Robert Gordon University K. Hui 2008-2009 19

 OOP Features
 4 major features in OOP
 encapsulation
 information hiding

 inheritance

 overloading

© The Robert Gordon University K. Hui 2008-2009 20

 Encapsulation
 an object encapsulates both its
attributes & methods
 implications:
 an attribute/ method is attached to an object/
class
 when you mention an attribute/ methods, you
have to specify which object/ class it comes from
 why encapsulation?
 when you get hold of an object, you also get hold
of its data & behaviour components
 good for reuse

© The Robert Gordon University K. Hui 2008-2009 21

 Information Hiding
 an object can hide its internal details
 e.g. you don’t know how your mobile’s electronics
works except punching the buttons
 can selectively show some details to the
outside world
 e.g. your mobile only shows the number it dials
 defines an “interface” to interact with the
outside world
 e.g. your mobile interacts with your through the
buttons & screen

© The Robert Gordon University K. Hui 2008-2009 22

 Why Information Hiding?
 the object can have a complex internal but
simple interface
 making interaction with the outside world easier
 you don’t need to know about the internal of
an object
 only the interface is important
 i.e. how to interact with it
 facilitate code reuse
 hiding any internal change from the outside world
by keeping the interface unchanged

© The Robert Gordon University K. Hui 2008-2009 23

 Inheritance
 a class may be similar to another
class but being more specialised
 e.g. the class “student” is similar to the
class “person” but “student” is more
specialised
 a person has attributes like: sex, age, name
 a student has all these + a student no.

© The Robert Gordon University K. Hui 2008-2009 24

 Inheritance (cont’d)
 a subclass
 extends/ specialises a superclass
 inherits attributes & methods from its superclass
 may have more attributes/ methods than its
superclass
 may change the content/ procedure of an inherited
method
 i.e. same method name/ signature but different behaviour
 why inheritance?
 reuse existing class definition
 customise/ specialise if needed

© The Robert Gordon University K. Hui 2008-2009 25

 Overloading
 different functions/ procedures/ methods can
have the same name
 provided that the parameters are of different
types
 giving a unique “signature”
 the system will figure out which one to invoke
 e.g. you can have 2 procedures, both named
“call”, taking a “dog” or “person” object as
parameter respectively. Depending on you give it
a “dog” or “person” object as the parameter, Java
will know which one to use.

© The Robert Gordon University K. Hui 2008-2009 26

 Why Overloading?
 you can call the same method (name)
but invoke different behaviour
 dynamic binding of method
 which method to invoke is determined at
runtime
 code reuse
 in term of the “calling” code

© The Robert Gordon University K. Hui 2008-2009 27

 Summary
 OOP models the world as objects
 classes are templates
 objects are instances of classes
 contain attributes (data) + methods (proce
dures)
 attributes & methods are attached to a
class or object
 OOP focuses on code reuse
© The Robert Gordon University K. Hui 2008-2009 28