TEST PPT

34
Object-Oriented Concepts & Design Principle Suntae Kim [email protected]

Transcript of TEST PPT

Object-Oriented Concepts & Design Principle

Suntae Kim

[email protected]

This Chapter in our course

Introduction To Design Patterns

Structural Patterns

Fundamental Design Patterns

Chapter 2

Chapter 3

Chapter 4

Chapter 5

Chapter 1 OO Concepts and Design Principle

Creational Patterns

Behavioral PatternsChapter 6

Page 2

Objectives: Concepts of Object Orientation

Review the basic principles of object orientation

Review the basic concepts and terms of object orientation and the associated UML notation

Review the strengths of object orientation

Review some basic UML modeling notation

Page 3

What Is Object Technology?

Object Technology

A set of principles guiding software construction together with languages, databases, and other tools that support those principles.

(Object Technology - A Manager’s Guide, Taylor, 1997)

Page 4

Strengths of Object Technology

A single paradigm- A single language used by users, analysts, designers, and implementers

Facilitates architectural and code reuse

Models more closely reflect the real world- More accurately describes corporate entities

- Decomposed based on natural partitioning

- Easier to understand and maintain

Stability- A small change in requirements does not mean massive changes in the system under

development

Adaptive to change

Page 5

What Is a Model?

A model is a simplification of reality.

Page 6

We build models to better understand the system we are developing.

Modeling achieves four aims. Modeling:- Helps us to visualize a system as we want it to be.- Permits us to specify the structure or behavior of a system.- Gives us a template that guides us in constructing a system.- Documents the decisions we have made.

We build models of complex systems because we cannot comprehend such a system in its entirety.

Why Do We Model?

Page 7

What Is an Object?

Informally, an object represents an entity, either physical, conceptual, or software.

- Physical entity

- Conceptual entity

- Software entity

Truck

Chemical Process

Linked List

Page 8

An object is an entity with a well-defined boundary and identity that encapsulates state and behavior.- State is represented by attributes and

relationships.- Behavior is represented by operations,

methods, and state machines.

A More Formal Definition

Object

Operations

Attributes

Page 9

An Object Has State

The state of an object is one of the possible conditions in which an object may exist.

The state of an object normally changes over time.

Name: J ClarkEmployee ID: 567138HireDate: 07/25/1991Status: TenuredDiscipline: FinanceMaxLoad: 3

Name: J ClarkEmployee ID: 567138Date Hired: July 25, 1991Status: TenuredDiscipline: FinanceMaximum Course Load: 3 classes

Professor Clark

Page 10

An Object Has Behavior

Behavior determines how an object acts and reacts.

The visible behavior of an object is modeled by the set of messages it can respond to (operations the object can perform).

Professor Clark’s behaviorSubmit Final GradesAccept Course OfferingTake Sabbatical Maximum Course Load: 3 classes

SubmitF

inal

Gra

des()

AcceptCourseOffering()

TakeSabbatical()

Professor Clark

SetMaxLoad()

Page 11

Each object has a unique identity, even if the state is identical to that of another object.

An Object Has Identity

Professor “J Clark” teaches Biology

Professor “K Steve” teaches Biology

Page 12

Basic Principles of Object Orientation

Object Orientation

Enca

psul

atio

n

Abs

trac

tion

Hie

rarc

hy

Mod

ular

ity

Page 13

The essential characteristics of an entity that distinguish it from all other kinds of entities

Defines a boundary relative to the perspective of the viewer

Is not a concrete manifestation, denotes the ideal essence of something

What Is Abstraction?

Page 14

Example: Abstraction

StudentProfessor

Course Offering (9:00 AM, Monday-Wednesday-Friday)

Course (e.g. Algebra)

Page 15

What Is Encapsulation?

Improves Resiliency

Hide implementation from clients. Clients depend on interface.

Page 16

Professor Clark needs to be able to teach four classes in the next semester.

Encapsulation Illustrated

SetMaxLoad(4)

SubmitF

inal

Gra

des()

AcceptCourseOffering()

TakeSabbatical()

Professor Clark

SetMaxLoad()

Name: J ClarkEmployee ID: 567138HireDate: 07/25/1991Status: TenuredDiscipline: FinanceMaxLoad:4

Page 17

Modularity is the breaking up of something complex into manageable pieces.

Modularity helps people to understand complex systems.

What Is Modularity?

Page 18

Example: Modularity

Course Registration System

?Billing System

Course Catalog System

Student Management System

Page 19

What Is Hierarchy?

Decreasing abstraction

Increasing abstraction

Elements at the same level of the hierarchy should be at the same level of abstraction.

Asset

RealEstate

Savings

BankAccount

Checking Stock

Security

Bond

Page 20

What Is Polymorphism?

Manufacturer AManufacturer B Manufacturer C

OO Principle:Encapsulation

The ability to hide many different implementations behind a sin-gle interface

Page 21

Example: Polymorphism

Stock Bond Mutual Fund

Get Current Value

getCurrentValue()

getCurrentValue()

getCurrentValue()

Page 22

A relationship among classes where one class shares the structure and/or behavior of one or more classes

Defines a hierarchy of abstractions in which a subclass inherits from one or more superclasses- Single inheritance- Multiple inheritance

Is an “is a kind of” relationship

Use delegation

What Is Generalization?

Page 23

Inheritance leverages the similarities among classes

A subclass inherits its parent’s attributes, operations, and relationships

A subclass may:- Add additional attributes, operations, relationships- Redefine inherited operations (use caution!)

Common attributes, operations, and/or relationships are shown at the highest applicable level in the hierarchy

What Gets Inherited?

Page 24

Design Principles

Page 25

Symptoms of Rotting Design(Poor Design) (1/3)

Rigidity( 경직성 )- Tendency for software to be difficult to change, even in simple way.- Every change causes a cascade of subsequent changes in dependent module.

Fragility( 깨지기 쉬운 )- Tendency of the software to break in many places every time it is changed.- Often the breakage occurs in areas that have no conceptual relationship with the

area that was changed.- Such software is impossible to maintain.

Page 26

Symptoms of Rotting Design(Poor Design) (2/3)

Immobility( 부동 )- Inability to reuse software from other projects or from parts of the same project.

Viscosity - Viscosity of the design( 끈적함 )- When faced with a change,

- 1) some of the ways preserve the design, - 2) others, doe not (e.g., that’s hack.)

- When the design preserving methods are harder to employ than the hacks, then the viscosity of the design is high.

It is easy to do the wrong thing, but hard to do the right thing.- Changes or additions are easier to implement by doing the wrong thing

- Reason : wrong design, rack of design comprehend, new software requirement

Page 27

Symptoms of Rotting Design(Poor Design) (3/3)

Needless Complexity( 불필요한 복잡성 )- Design contains elements that are not currently useful

- Too much anticipation of future needs- Agile principles state that you should never anticipate future needs

- Extra complexity is needed only when designing an application framework or customizable component.

- You aren’t going need it

Needless Repetition- The same code appears over and over again, in slightly different forms

- developers are missing an abstraction- bugs found in a repeating unit have to be fixed in every repetition

Page 28

Principles of Object-Oriented Class Design

Five Principles to Avoid the Symptoms of Rotting Design- The Single-Responsibility Principle(SRP)- The Open Close Principle(OCP)- The Liskov Substitution Principle(LSP)- The Dependency Inversion Principle(DIP)- The Interface Segregation Principle(ISP)

Page 29

The Single-Responsibility Principle (SRP)

“A class should have only one reason to change.”

Rationale behind SRP- changes in requirements changes in class responsibilities- a ‘cohesive’ responsibility is a single axis of change a class should have only

one responsibility- responsibility = A reason to change

Violation of SRP causes spurious transitive dependencies between modules that are hard to anticipate. fragility

E.g., Bowling Game Class associating with Score and Stage Management.

Page 30

Open/Close Principle(OCP)

“Software entities should be open for extension, but closed for modification.”

You don’t have to change the class but to extend it. 

New functionality should be added with minimum changes in the existing code.

Reduce Rigidity : a change does not cause a cascade of related changes in dependent module.

<Bad Design> <Good Design>

GraphicEditor

+drawCircle():void+drawRectangle():void+drawShape():void

Rectangle Shape Circle

GraphicEditor

+drawShape(s:Shape):void

Rectangle

Shape

Circle

draw():void draw():void

draw():void

If(s.type=1) drawRectangle();Else if(s.type=2) drawCircle();

{ s.draw();}

Page 31

The Liskov Substitution Principle(LSP)

“Subtypes must be substitutable for their base types.”

A user of a base class should continue to function properly if a derivative of that base is passed to it.

public abstract class Bird { public abstract void fly();}

public class Parrot extends Bird { public void fly() { /* implementation */ } public void speak() { /* implementation */ }}

public class Penguin extends Bird { public void fly() { throw new UnsupportedOperationException(); }}

Bird myPet = new Parrot();myPet.fly(); // myPet "is-a" bird and can fly()

Bird myOtherPet = new Penguin();myOtherPet.fly(); // myOtherPet "is-a" bird// and cannot fly()?!

Penguin is not a subtype of Bird!

A user should know the specific subtype.

Page 32

Dependency Inversion Principle(DIP)

"High-level modules should not depend on low-level modules. Both should depend on abstractions.

Abstractions should not depend on details. Details should depend on abstractions."

< Bad Design> < Good Design >

Manager

+setWorker(Worker)+setSuperWorker(SuperWorker)+manage()

Worker SuperWorker

IWorker

+ work() + work()

Worker SuperWorker

+ work() + work()

Manager

+setWorker(IWorker)+manage()

+ work()

< Good Design >

Page 33

Interface-Segregation Principle(ISP)

“Clients should not be forced to depend upon methods that they do not use.”

Many client specific interfaces are better than one general purpose interface- no ‘fat’ interfaces- no non-cohesive interfaces

Related to SRP

E.g., Input and Output interfaces

Page 34