TEST PPT
Transcript of TEST PPT
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
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
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