Object-Oriented Concepts

processroguishSoftware and s/w Development

Nov 18, 2013 (3 years and 11 months ago)

93 views

CS540 Software Design

2

Lecture 13

Object
-
Oriented Programming


Objects can be used effectively to represent real
-
world entities


For instance, an object might represent a
particular employee in a company


Each employee object handles the processing
and data management related to that employee

3

Objects


An object has:


state

-

descriptive characteristics


behaviors

-

what it can do (or what can be done to it)


The state of a bank account includes its account number and its
current balance


The behaviors associated with a bank account include the ability
to make deposits and withdrawals


Note that the behavior of an object might change its state

CS540 Software Design

4

Lecture 13

Classes


An object is defined by a
class


A class is the blueprint of an object


Multiple objects can be created from the same class

CS540 Software Design

5

Lecture 13

Objects and Classes

Bank
Account

A class

(the concept)

John’s Bank Account

Balance: $5,257

An object

(the realization)

Bill’s Bank Account

Balance: $1,245,069

Mary’s Bank Account

Balance: $16,833

Multiple objects

from the same class

CS540 Software Design

6

Lecture 13

Attributes

Contain current state of an object.



Attributes can be classified as simple or complex.


Simple attribute can be a primitive type such as integer,
string, etc., which takes on literal values.


Complex attribute can contain collections and/or
references.


Reference attribute represents relationship.


complex object:

contains one or more complex
attributes




CS540 Software Design

7

Lecture 13

Methods and messages

Method
:
Defines behavior of an object, as a set of encapsulated functions.

Message:
Request from one object to another asking second object to
execute one of its methods.






(a)

(b)

(a) Object showing attributes and methods

(b) Example of a method

CS540 Software Design

8

Lecture 13

Classes

Class
: Blueprint for defining a set of similar objects.




Objects in a class are called
instances
.


CS540 Software Design

9

Lecture 13

Inheritance


One class can be used to derive another via
inheritance


Classes can be organized into hierarchies

Bank
Account

Account

Charge
Account

Savings
Account

Checking
Account

CS540 Software Design

10

Lecture 13

Inheritance (contd)

Inheritance allows one class of objects to be defined as a special case of a more general
class.


Special cases are
subclasses

and more general cases are
superclasses
.



Generalization: process of forming a superclass

Specialization: forming a subclass


Subclass inherits all properties of its superclass
and

can define its own unique
properties.


Subclass can redefine inherited methods.


All instances of subclass are instances of superclass.


Principle of substitutability
: instance of subclass can be used whenever method/construct
expects instance of superclass.


A KIND OF (AKO): Name for relationship between subclass and superclass

CS540 Software Design

11

Lecture 13

Types of inheritance



(a)

(b)

(c)

(a) Single

(b) Multiple

(c) Repeated

(b)

CS540 Software Design

12

Lecture 13

Inheritance (contd)


Define
humanBeing

to be a
class


A
humanBeing

has
attributes
, such as age, height,
gender


Assign values to attributes when describing object


Define Parent to be a
subclass

of HumanBeing


A Parent has all attributes of a HumanBeing, plus
attributes of his/her own (name of oldest child,
number of children)


A

Parent

inherits all attributes of
humanBeing


The property of inheritance is an essential feature of
object
-
oriented languages such as Smalltalk, C++, Ada
95, Java (but not C, FORTRAN)

CS540 Software Design

13

Lecture 13

Inheritance (contd)


UML notation


Inheritance is represented by a large open triangle

CS540 Software Design

14

Lecture 13

Java implementation

CS540 Software Design

15

Lecture 13

Overriding and Overloading

Overriding:
Process of redefining a property within a subclass.

Overloading:
Allows name of a method to be reused with a class or across
classes.


Overriding Example:

Might define method in Staff class to increment salary based on commission


method void giveCommission(float branchProfit) {


salary = salary + 0.02 * branchProfit; }


May wish to perform different calculation for commission in Manager subclass:


method void giveCommission(float branchProfit) {


salary = salary + 0.05 * branchProfit; }

CS540 Software Design

16

Lecture 13

Aggregation


UML Notation

CS540 Software Design

17

Lecture 13

Association


UML Notation

CS540 Software Design

18

Lecture 13

Equivalence of Data and Action


Classical paradigm


record_1.field_2


Object
-
oriented paradigm


thisObject.attributeB


thisObject.methodC()

CS540 Software Design

19

Lecture 13

Example


Chapter 7 Schach (2002)


Design of an operating system for a large mainframe
computer. It has been decided that batch jobs submitted
to the computer will be classified as high priority,
medium priority, or low priority. There must be three
queues for incoming batch jobs, one for each job type.
When a job is submitted by a user, the job is added to
the appropriate queue, and when the operating system
decides that a job is ready to be run, it is removed from
its queue and memory is allocated to it


Design 1 (Next slide)


Low cohesion

operations on job queues are spread all over
product

CS540 Software Design

20

Lecture 13

Data Encapsulation


Design 1

CS540 Software Design

21

Lecture 13

Data Encapsulation


Design 2

CS540 Software Design

22

Lecture 13

Data Encapsulation


m_encapsulation

has informational cohesion


m_encapsulation
is an implementation of data
encapsulation


Data structure (
job_queue
) together with operations
performed on that data structure


Advantages


Development


Maintenance

CS540 Software Design

23

Lecture 13

Data Encapsulation and
Development


Data encapsulation is an example of
abstraction



Job queue example


Data structure


job_queue


Three new functions


i
nitialize_job_queue


add_job_to_queue


delete_job_from_queue


Abstraction


Conceptualize problem at higher level


job queues and operations on job queues


not lower level


records or arrays

CS540 Software Design

24

Lecture 13

Stepwise Refinement

Step 1: Design in terms of high level concepts

It is irrelevant how job queues are implemented

Step 2: Design low level components

Totally ignore what use will be made of them


In 1st step, assume existence of lower level


Concern is the behavior of the data structure


job_queue


In 2nd step, ignore existence of high level


Concern is the implementation of that behavior


In a larger product, there will be many levels of abstraction

CS540 Software Design

25

Lecture 13

Data Encapsulation and
Maintenance


Identify aspects of product likely to change


Design product so as to minimize the effects
of change


Data structures are unlikely to change


Implementation may change


Data encapsulation provides a way to cope
with change

CS540 Software Design

26

Lecture 13

Implementation of
Class

JobQueue

C++










Jav
a


CS540 Software Design

27

Lecture 13

Implementation of queueHandler

C++ Java


CS540 Software Design

28

Lecture 13

Data Encapsulation and
Maintenance (contd)


What happens if queue is now implemented as a two
-
way linked
list of
JobRecord
?


Module that uses
JobRecord

need not be changed at all,
merely recompiled




C++







Java

CS540 Software Design

29

Lecture 13

Abstract Data Types


Problem with both implementations


Only one queue


Need


We need:


Data
type

+ operations performed on instantiations
of that data type


Abstract data type

CS540 Software Design

30

Lecture 13

Abstract Data Type (contd)


(Problems caused by
public

attributes solved later)

CS540 Software Design

31

Lecture 13

Information Hiding


Data abstraction


Designer thinks at level of an ADT


Procedural abstraction


Define a procedure

extend the language


Instances of a more general design concept,
information hiding


Design the modules in way that items likely to change are
hidden


Future change is localized


Changes cannot affect other modules

CS540 Software Design

32

Lecture 13

Information Hiding (contd)


C++ abstract
data type
implementation
with information
hiding

CS540 Software Design

33

Lecture 13

Information Hiding (contd)


Effect of information hiding via
private

attributes


CS540 Software Design

34

Lecture 13

Polymorphism and Dynamic
Binding


Classical paradigm


Must explicitly invoke correct version

CS540 Software Design

35

Lecture 13

Polymorphism and Dynamic Binding
(contd)


Object
-
oriented paradigm

CS540 Software Design

36

Lecture 13

Polymorphism and Dynamic
Binding (contd)


All that is needed is
myFile.open()


Correct method invoked at run
-
time (dynamically)


Method
open

can be applied to objects of
different classes


Polymorphic

CS540 Software Design

37

Lecture 13

Polymorphism and dynamic binding
(contd)


Method

checkOrder (b : Base)

can be applied to objects of any subclass
of

Base

CS540 Software Design

38

Lecture 13

Polymorphism and Dynamic
Binding (contd)


Can have a negative impact on maintenance


Code is hard to understand if there are multiple
possibilities for a specific method


Polymorphism and dynamic binding


Strength and weakness of the object
-
oriented paradigm

CS540 Software Design

39

Lecture 13

Polymorphism and dynamic binding
(contd)

Polymorphism:
Means ‘
many forms
’.


Dynamic Binding:

Runtime process of selecting appropriate method based on
an object’s type.


Example:

With list consisting of an arbitrary no. of objects from the Staff hierarchy,
we can write:


list[i]. print


and runtime system will determine which print() method to invoke depending on
the object’s (sub)type.

CS540 Software Design

40

Lecture 13

Cohesion and Coupling of Objects


No such thing!


Object
-
oriented cohesion and coupling always reduces to
classical cohesion


The only feature unique to the object
-
oriented paradigm is
inheritance


Cohesion has nothing to do with inheritance


Two objects with the same functionality have the same
cohesion


It does not matter if this functionality is inherited or not


Similarly, so
-
called object
-
oriented coupling always reduces to
classical coupling

CS540 Software Design

41

Lecture 13

Object
-
Oriented Metrics (contd)


Two types of so
-
called object
-
oriented metric


Not related to inheritance


Reduces to a classical metric


Inheritance
-
related


May reduce to a classical metric


No problem


Classical metrics work just fine


But don’t mislead others by calling them object
-
oriented

CS540 Software Design

42

Lecture 13

Advantages of Objects


Same as as advantages of abstract data types


Information hiding


Data abstraction


Procedural abstraction


Inheritance provides further data abstraction


Easier and less error
-
prone product
development


Easier maintenance


Objects are more reusable than modules with
functional cohesion

CS540 Software Design

43

Lecture 13

Summary