Object-Oriented Programming

Objects can be used effectively to represent realworld 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

CS540 Software Design

Lecture 13

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

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

Lecture 13

Objects and Classes

A class (the concept)
Bank Account

An object (the realization)

Johns Bank Account Balance: $5,257 Bills Bank Account Balance: $1,245,069 Marys Bank Account Balance: $16,833

Multiple objects from the same class

CS540 Software Design

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

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.

(b)

(a) Object showing attributes and methods (b) Example of a method

(a)
CS540 Software Design Lecture 13 7

Classes
Class: Blueprint for defining a set of similar objects.

Objects in a class are called instances.

CS540 Software Design

Lecture 13

One class can be used to derive another via inheritance Classes can be organized into hierarchies
Account

Inheritance

Charge Account

Bank Account

Savings Account

Checking Account

CS540 Software Design

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

Lecture 13

10

Types of inheritance

(a) (b)

(a) Single (b) Multiple (c) Repeated (c)

CS540 Software Design Lecture 13 11

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)
Lecture 13 12

CS540 Software Design

Inheritance (contd)

UML notation Inheritance is represented by a large open triangle

Lecture 13 13

CS540 Software Design

Java implementation

CS540 Software Design

Lecture 13

14

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

Lecture 13

15

Aggregation

CS540 Software Design

UML Notation
Lecture 13 16

Association

UML Notation

CS540 Software Design

Lecture 13

17

Equivalence of Data and Action

Classical paradigm

record_1.field_2
thisObject.attributeB thisObject.methodC()

Object-oriented paradigm

CS540 Software Design

Lecture 13

18

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 cohesionoperations on job queues are spread all over product
Lecture 13 19

CS540 Software Design

Data Encapsulation Design 1

CS540 Software Design

Lecture 13

20

Data Encapsulation Design 2

CS540 Software Design

Lecture 13

21

Data Encapsulation

has informational cohesion m_encapsulation is an implementation of data encapsulation

m_encapsulation

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

Advantages
Development Maintenance

CS540 Software Design

Lecture 13

22

Data encapsulation is an example of abstraction Job queue example

Data Encapsulation and Development

Data structure

job_queue

Three new functions

initialize_job_queue
add_job_to_queue delete_job_from_queue

Abstraction

Conceptualize problem at higher level

job queues and operations on job queues records or arrays

not lower level

CS540 Software Design

Lecture 13

23

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

Lecture 13

24

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

Lecture 13

25

Implementation of Class JobQueue C++

CS540 Software Design

Lecture 13

26

Implementation of queueHandler

C++
CS540 Software Design Lecture 13

Java
27

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 Lecture 13 28

Abstract Data Types

Problem with both implementations

Only one queue

We need: Data type + operations performed on instantiations of that data type

Need

Abstract data type

CS540 Software Design

Lecture 13

29

Abstract Data Type (contd)

(Problems caused by public attributes solved later)

Lecture 13 30

CS540 Software Design

Information Hiding

Data abstraction Designer thinks at level of an ADT Procedural abstraction Define a procedureextend 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

Lecture 13

31

Information Hiding (contd)

C++ abstract data type implementation with information hiding

CS540 Software Design

Lecture 13

32

Information Hiding (contd)

Effect of information hiding via private attributes

Lecture 13 33

CS540 Software Design

Polymorphism and Dynamic Binding

Classical paradigm

Must explicitly invoke correct version

CS540 Software Design

Lecture 13

34

Polymorphism and Dynamic Binding (contd)

Object-oriented paradigm
Lecture 13 35

CS540 Software Design

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

Lecture 13

36

Polymorphism and dynamic binding (contd)

Method checkOrder (b : Base) can be applied to objects of any subclass of Base

CS540 Software Design Lecture 13 37

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 Strength and weakness of the object-oriented paradigm

Polymorphism and dynamic binding

CS540 Software Design

Lecture 13

38

Polymorphism and dynamic binding (contd)

Polymorphism: Means many forms.

Dynamic Binding: Runtime process of selecting appropriate method based on an objects 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 objects (sub)type.

CS540 Software Design

Lecture 13

39

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
Lecture 13 40

CS540 Software Design

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 dont mislead others by calling them objectoriented

CS540 Software Design

Lecture 13

41

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
Lecture 13 42

CS540 Software Design

Summary

CS540 Software Design

Lecture 13

43