TEST PPT

1. Object-Oriented Concepts &
Design Principle
Suntae Kim
stkim@jbnu.ac.kr

2. 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

3. 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

4. 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

5. 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

6. What Is a Model?
 A model is a simplification of reality.
Page  6

7.  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

8. 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

9.  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

10. 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 Clark
Employee ID: 567138
HireDate: 07/25/1991
Status: Tenured
Discipline: Finance
MaxLoad: 3
Name: J Clark
Employee ID: 567138
Date Hired: July 25, 1991
Status: Tenured
Discipline: Finance
Maximum Course Load: 3 classes
Professor Clark
Page  10

11. 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 behavior
Submit Final Grades
Accept Course Offering
Take Sabbatical
Maximum Course Load: 3 classes
TakeSabbatical()
Professor Clark
Page  11

12.  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

13. Basic Principles of Object Orientation
Object Orientation
Encapsulation
Abstraction
Hierarchy
Modularity
Page  13

14.  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

15. Example: Abstraction
Student
Professor
Course Offering (9:00 AM,
Monday-Wednesday-Friday)
Course (e.g. Algebra)
Page  15

16. What Is Encapsulation?
Improves Resiliency
 Hide implementation from clients.
 Clients depend on interface.
Page  16

17.  Professor Clark needs to be
able to teach four classes in
the next semester.
Encapsulation Illustrated
SetMaxLoad(4)
TakeSabbatical()
Professor Clark
Name: J Clark
Employee ID: 567138
HireDate: 07/25/1991
Status: Tenured
Discipline: Finance
MaxLoad:4
Page  17

18.  Modularity is the breaking up of something complex into
manageable pieces.
 Modularity helps people to understand complex systems.
What Is Modularity?
Page  18

19. Example: Modularity
Course Registration
System
?
Billing System
Course Catalog System
Student Management System
Page  19

20. 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

21. What Is Polymorphism?
Manufacturer A
Manufacturer B
Manufacturer C
OO Principle:
Encapsulation
 The ability to hide many different implementations behind a
single interface
Page  21

22. Example: Polymorphism
Stock Bond Mutual Fund
Get Current Value
Page  22

23.  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

24. 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

25. Design Principles
Page  25

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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