The Object-Oriented Paradigm

processroguishΛογισμικό & κατασκευή λογ/κού

18 Νοε 2013 (πριν από 3 χρόνια και 8 μήνες)

74 εμφανίσεις

Chapter One


The Object
-
Oriented Paradigm


Ku
-
Yaw Chang

canseco@mail.dyu.edu.tw


Assistant Professor, Department of

Computer Science and Information Engineering

Da
-
Yeh University

2

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Outline

Overview

Before the Object
-
Oriented Paradigm: Functional
Decomposition

The Problem of Requirements

Dealing with Changes: Using Functional Decomposition

Dealing with Changing Requirements

The Object
-
Oriented Paradigm

Object
-
Oriented Programming in Action

Special Object Methods

Summary

3

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Overview

Object
-
Oriented Paradigm


Compare and contrast with

Standard Structured Programming

Contents


Functional decomposition


Problem of requirements


Object
-
oriented paradigm


Special object methods


Important object terminology

4

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Outline

Overview

Before the Object
-
Oriented Paradigm:
Functional Decomposition

The Problem of Requirements

Dealing with Changes: Using Functional
Decomposition

Dealing with Changing Requirements

The Object
-
Oriented Paradigm

Object
-
Oriented Programming in Action

Special Object Methods

Summary

5

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Functional Decomposition

A natural way to deal with complexity

Example:

You are given a task to write code to


Access a description of shapes that were
stored in a database


Display shapes

6

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Functional Decomposition

It would be natural to think in terms of the
steps required:

1.
Locate the list of shapes in the database.

2.
Open up the list of shapes.

3.
Sort the list according to some rules.

4.
Display the individual shapes on the monitor.

7

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Functional Decomposition

Further break down Step 4.

1.
Locate the list of shapes in the database.

2.
Open up the list of shapes.

3.
Sort the list according to some rules.

4.
Display the individual shapes on the monitor.

a)
Identify type of shape.

b)
Get location of shape.

c)
Call appropriate function that will display shape,
giving it the shape’s location.

8

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Functional Decomposition

A natural way to deal with complexity


Break down (decompose) the problem into
the functional steps that compose it.

Challenge


Not help us prepare the code for possible
changes in the future

Dealing with change


a graceful evolution

9

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Functional Decomposition

Many bugs originate with changes to
code.


Change creates opportunities for mistakes
and unintended consequences.

Nothing you can do will stop change. But
you do not have to be overcome by it.


You can never get all of requirements from
the user.


Too much is unknown about the future


things change.

10

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Outline

Overview

Before the Object
-
Oriented Paradigm:
Functional Decomposition

The Problem of Requirements

Dealing with Changes: Using Functional
Decomposition

Dealing with Changing Requirements

The Object
-
Oriented Paradigm

Object
-
Oriented Programming in Action

Special Object Methods

Summary

11

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

The Problem of Requirements

Requirements from users are


Incomplete


Usually wrong


Misleading


Do not tell the whole story

Requirements always change.


A bad thing


Few write their code to handle changing
requirement

12

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

The Problem of Requirements

Requirements change for a very simple set of
reasons:


The users see new possibilities for the software after
discussions with developers.


Developers become more familiar with users’ problem
domain.


The environment in which the software is being
developed changes.

Must write our code to accommodate change


Not give up on gathering good requirements

13

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Outline

Overview

Before the Object
-
Oriented Paradigm:
Functional Decomposition

The Problem of Requirements

Dealing with Changes: Using Functional
Decomposition

Dealing with Changing Requirements

The Object
-
Oriented Paradigm

Object
-
Oriented Programming in Action

Special Object Methods

Summary

14

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Dealing with Changes:

Using Functional Decomposition

Using modularity to contain variation


Make code more modular

Step 4c of displaying shapes


Call appropriate function that will display shape, giving it the
shape’s location




function : display shape


input: type of shape, description of shape


action:


switch (type of shape)



case square
:



put display function for square here



case circle
:




put display function for circle here

15

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Problems with Modularity

May or may not be possible to have
a
consistent description

of shapes that will
work for all shapes

Modularity


Make the code more understandable


Understandability

Make the code easier to maintain


Does not deal with all of the variation it might
encounter

16

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Low Cohesion and Tight Coupling

Cohesion


How closely the operations in a routine are related

Coupling


The strength of a connection between two routines

Goal


To create routines with internal integrity (
strong
cohesion
) and small, direct, visible, and flexible
relations to other routines (
loose coupling
)

17

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Unwanted Side Effect

Unwanted side effect


Make a change to a function or piece of data in one
area of the code

Have an unexpected impact on other pieces of code

We really do not spend much time fixing bugs.


The overwhelming amount of time spent in
maintenance and debugging is on

Finding bugs

Avoiding unwanted side effects

18

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Wrong Focus

Changes to one set of functions or data
impact other sets of functions and other
sets of data


In turn impact other functions that must be
changed

Like a snowball that picks up snow as it rolls
downhill

19

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Outline

Overview

Before the Object
-
Oriented Paradigm:
Functional Decomposition

The Problem of Requirements

Dealing with Changes: Using Functional
Decomposition

Dealing with Changing Requirements

The Object
-
Oriented Paradigm

Object
-
Oriented Programming in Action

Special Object Methods

Summary

20

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Dealing with

Changing Requirements

How do people do thing?

Example


You were an instructor at a conference


People in your class had another class to attend
following yours, but didn’t know where it was located.

Structured programming approach

1.
Get list of people in the class.

2.
For each person on this list:

a.
Find the next class they are taking

b.
Find the location of that class

c.
Find the way to get from your classroom to the person’s
next class

d.
Tell the person how to get to their next class

21

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Dealing with

Changing Requirements

Require following procedures

1.
A way of getting the list of people in the class

2.
A way of getting the schedule for each person in the
class

3.
A program that gives someone directions from your
classroom to any other classroom

4.
A control program that works for each person in the
class and does the required steps for each person

Would you actually follow this approach?


Post directions in the back of the room


Expect everyone would know what their next class
was

22

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Difference

First case


Give
explicit directions

to everyone.


No one other than you is responsible for anything.

Second case


Give
general instructions


Each person figure out how to do the task himself or
herself

Shift of responsibility


The same thing must be implemented.


The organization is very different.

23

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

The Impact

New requirements


Give special instructions to graduate students
who are assisting at the conference

Collect course evaluations

Take them to the conference office before going to
the next class

24

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Why the Difference

First case


Modify the control program to distinguish the graduate
students from the undergraduates


Give special instructions to the graduate students

Modify the program considerably

Second case


Write an additional routine for graduate students to
follow


Control program remains the same

Significant difference


Control program

25

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

What Makes It Happen

The people are responsible for themselves


Instead of the control program being
responsible for them

The control program can talk to different
types of people as if they were exactly the
same

The control program does not need to
know about any special steps

26

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Perspectives in the

Software Development Process

Conceptual


The concepts in the domain under study


With little or no regard for the software that
might implement it

Specification


Look at the interface of the software, not
implementation

Implementation


Look at the code itself

27

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

How Perspectives Help

Conceptual level


Go to your next class


What to do, not how to do

Implementation level


The way they go to their class

Communicating at one level (conceptually) while
performing at another level (implementation)


The requestor (the instructor) does not know exactly
what is happening

Only know conceptually what is happening

28

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Outline

Overview

Before the Object
-
Oriented Paradigm:
Functional Decomposition

The Problem of Requirements

Dealing with Changes: Using Functional
Decomposition

Dealing with Changing Requirements

The Object
-
Oriented Paradigm

Object
-
Oriented Programming in Action

Special Object Methods

Summary

29

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

The Object
-
Oriented Paradigm

Centered on the concept of the object

Object


Data with methods

Data (Attributes) can be simple things like number
or character strings, or they can be other objects


Define things that are responsible for
themselves

Data: to know what state it is in

Method (Code): to function properly

30

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Objects and Their Responsibilities

This Object…

Is Responsible For

Student

Knowing which classroom they are in

Know which classroom they are to go to next

Going from one classroom to the next classroom

Instructor

Telling people to go to next classroom

Classroom

Having a location

Direction Giver

Given two classrooms, giving directions from one
classroom to the other

31

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

How to Think About Objects

Objects


Something with responsibilities

A good design rule


Objects should be responsible for themselves
and should have those responsibilities clearly
defined

32

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

How to Think About Objects

At the conceptual level


An object is a set of responsibilities

At the specification level


An object is a set of methods that can be
invoked by other objects or by itself

At the implementation level


An object is code and data

33

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Public Interface

Many methods of an object will be identified as
callable by other objects.

The collection of these methods is called the
object’s
public interface


Student

object with the method gotoNextClassroom()


More kinds of students

Inefficient for each student type to have its own set of
methods

A more efficient approach


A general student to contain common methods


Be used or tailored to their needs

34

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

The Object
-
Oriented Paradigm

A class is a definition of the behavior of an
object, containing a complete description of


The data elements the object contains


The methods the object can do


The way these data elements and methods can be
accessed

Objects are
instances

of classes


Creating instances of a class is called
instantiation


Each object of the same type

Different data, but have the same functionality

35

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Go to the Next Classroom

1.
Start the control program

2.
Instantiate the collection of students in the classroom

3.
Tell the collection to have the students go to their next
class

4.
The collection tells each students to go to their next
class

5.
Each student


Finds where his next class is


Determines how to get there


Goes there

6.
Done

36

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

The Need for an Abstract Type

The dilemma


Allow any type of student into the collection


The collection is an array or something of some type
of object

RegularStudent

GraduateStudent

The solution


A general type that encompasses more than one
specific type

Student : an
abstract class


RegularStudent


GraduateStudent

37

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Abstract Class

Abstract class define what other, related
classes can do.


These “other” classes represent a particular
type of related behavior.


Such a class is often called a
concrete class
.

The abstract class is Student


Concrete classes are RegularStudent and
GraduateStudent

RegularStudent is one kind of Student

GraduateStudent is one kind of Student

38

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Abstract Class

Inheritance


An
is
-
a

relationship

RegularStudent class inherits from Student


Derives from


Specializes


A
subclass

of

Student class is the base class of
GraduateStudent and of RegularStudent


Generalizes


A
superclass

of

39

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Abstract Class

Placeholders for other classes


Define the methods their derived classes
must implement


Contain common methods that can be used
by all derivations

Controller contains Students


The collection only needs to deal with
Students


Each kind of Student is left to implement its
functionality in its own way

40

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Visibility

Public


Anything can see it

Protected


Only objects of this class and derived classes
can see it

Private


Only objects from this class can see it

41

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Encapsulation and Polymorphism

Encapsulation


Hiding data

In general, any kind of hiding

Polymorphism


Poly : many


Morph : form


Different behavior

Depend upon the specific type of derived object

42

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Review of OO Terminology

Object

Class

Encapsulation

Inheritance

Instance

Instantiation

Polymorphism

Perspectives

43

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Outline

Overview

Before the Object
-
Oriented Paradigm:
Functional Decomposition

The Problem of Requirements

Dealing with Changes: Using Functional
Decomposition

Dealing with Changing Requirements

The Object
-
Oriented Paradigm

Object
-
Oriented Programming in Action

Special Object Methods

Summary

44

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

New Example

Shape Example

1.
Locate the list of shapes in the database

2.
Open up the list of shapes

3.
Sort the list according to some rules

4.
Display the individual shapes on the monitor

45

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Objects in Shape Program

ShapeDataBase


getCollection


get a specified collection of shapes

Shape

(an abstract class)


display


defines interface for Shapes


getX


return X location of Shape


getY


return Y location of Shape

Square

(derived from Shape)


display


display a square (represented by this object)

Circle

(derived from Shape)


Display


display a circle (represented by this object)

46

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Objects in Shape Program

Collection


display


tell all contained shapes to display


sort


sort the collection of shapes

Display


drawLine


draw a line on the screen


drawCircle


draw a circle on the screen

47

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Main Program

Create an instance of the database object

Ask the database object to find the set of shapes


Instantiate a collection object containing all of the
shapes

Ask the collection to sort the shapes

Ask the collection to display the shapes

The collection asks each shape to display itself

Each shape display itself

48

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

New Requirements

Add new kinds of shapes (such as a
triangle)


Create a new derivation of Shape that defines
the shape.


Implement a version of the display method
that is appropriate for that type

Change the sorting algorithm


Modify the method in Collection. Every shape
will use the new algorithm

49

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Encapsulation Revisited

Using things is easier


User does not need to worry about
implementation issues

Implementations can be changed without
worrying about the caller

The insides of an object are unknown to
outside objects

50

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Benefits

The more I make my objects responsible
for their own behaviors, the less the
controlling programs have to be
responsible for.

Encapsulation makes changes to an
object’s internal behavior transparent to
other objects.

Encapsulation helps to prevent unwanted
side effects

51

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Outline

Overview

Before the Object
-
Oriented Paradigm:
Functional Decomposition

The Problem of Requirements

Dealing with Changes: Using Functional
Decomposition

Dealing with Changing Requirements

The Object
-
Oriented Paradigm

Object
-
Oriented Programming in Action

Special Object Methods

Summary

52

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Special Object Methods

Constructor


A special method that is automatically called when
the object is created


Handle starting up the object

To eliminate uninitialized variables

Destructor


A special method that helps an object clean up after
itself when the object is destroyed


Release resources


Java

Garbage collection

53

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Outline

Overview

Before the Object
-
Oriented Paradigm:
Functional Decomposition

The Problem of Requirements

Dealing with Changes: Using Functional
Decomposition

Dealing with Changing Requirements

The Object
-
Oriented Paradigm

Object
-
Oriented Programming in Action

Special Object Methods

Summary

54

Ku
-
Yaw Chang

The Object
-
Oriented Paradigm

Summary

Object orientation helps us minimize
consequences of shifting requirements


In contrast with functional decomposition

Essential concepts and primary
terminology in object
-
oriented
programming

The End