Extras din document
The Plan
• Introducing fundamental patterns (1
week)
• 21 design patterns will be covered
based on the case study presented in
the text book (9 weeks):
– Design Patterns: Elements of
Reusable Object-Oriented Software
• Remaining 2 patterns will be presented
as an exercise for designing a compiler
system (1 week)
• Last 3 lectures will be devoted to
another case study - Designing a Payroll
System – consolidate patterns usage
Definition
• A pattern describes a problem which occurs over and over
again in our environment, and then describes the core of the
solution to that problem, in such a way that you can use this
solution a million times over, without ever doing it the same way
twice. [Christopher Alexander, Sara Ishikawa, Murray Silverstein,
Max Jacobson, Ingrid Fiksdahl-King, and Shlomo Angel. A Pattern
Language. Oxford University Press, New York, 1977]
• 5 essential elements:
– Pattern name
– Problem description
– Solution
– Consequences
– Implementation
Șabloane de proiectare
Types of Patterns
• Architectural Patterns: MVC, Layers
• Design Patterns: Singleton, Observer etc
– We’ll cover these ones in this course
• GUI Design Patterns: Window per task, Disabled irrelevant things,
Explorable interface
• Database Patterns: decoupling patterns, resource patterns, cache
patterns
• Concurrency Patterns: Double buffering, Lock object, Producerconsumer,
Asynchronous processing
• Enterprise (J2EE) Patterns: Data Access Object, Data Transfer Object
• GRASP (General Responsibility Assignment Patterns): Low
coupling/high cohesion, Controller, Law of Demeter (don’t talk to
strangers), Expert, Creator
• Anti-patterns = bad solutions largely observed: God class,
Singletonitis, Basebean, CallSuper
OOD Key Principles
Motto: “Imitation is the sincerest form of not being stupid.”
DEFINITION [Design principle] A design principle is a basic tool or technique that can be
applied to designing or writing code to make that code more maintainable, flexible, or
extensible.
Key OOD principles are (S.O.L.I.D):
• SRP
• OCP
• LSP
• ISP
• DIP
CODE should BE readable, extendable, modifiable, testable, refactorable etc.
Single Responsibility Principle
A class should have one and only one reason to change, meaning that a
class should have only one job.
ONLY one reason to change something!
Code will be simpler and easier to maintain.
Example: Container and Iterator (Container manages objects; Iterator traverses the
container)
How to spot multiple responsibilities? Forming sentences ending in itself.
Single Responsibility Principle
Automobile
Start()
Stop()
ChangeTires()
Drive()
GetOilLevel()
The Automobile start itself.
The Automobile stop itself.
The Automobile changeTires itself.
The Automobile Drive itself.
The Automobile getOilLevel itself.
Automobile
Start()
Stop()
GetOilLevel()
Driver
Drive(Automobile)
Mechanic
ChangeTires(Automobile)
NOK
OK
A class should have one and only one reason to change, meaning that a
class should have only one job.
ONLY one reason to change something!
Code will be simpler and easier to maintain.
Example: Container and Iterator (Container manages objects; Iterator traverses the
container)
How to spot multiple responsibilities? Forming sentences ending in itself.
Open-Close Principle
Classes should be open for extension and closed for modification.
Allowing change, but without modifying existing code. It offers flexibility.
Use inheritance to extend/change existing working code and don’t touch working code.
OCP can also be achieved using composition.
Open-Close Principle
Classes should be open for extension and closed for modification.
Allowing change, but without modifying existing code. It offers flexibility.
Use inheritance to extend/change existing working code and don’t touch working code.
OCP can also be achieved using composition.
Preview document
Conținut arhivă zip
- Sabloane de proiectare.pdf