COMP 310
|
Lec07: Designing a Ball |
Design Pattern | CS Principle(s) |
Union | Polymorphism, inheritance |
Composite | Recursive data structures |
Visitor | Decoupled data and algorithms |
Strategy | Delegation to abstract processes/behaviors with known semantics |
Command | Delegation to abstract processes/behaviors with unknown semantics |
State | Dynamic reclassification -- objects that have changeable states and hence changeable behaviors. Also, encapsulation barriers to decouple changes. |
Model-View-Controller | Dcomposition of a system into decoupled modules |
Adapter | Use of indirection layers for decoupling and communication via syntatic translations |
Intepreter | Data-driven algorithms, polymorphic dispatching, and recusion. |
Factory | Abstraction of the creation process of an entity |
Template | Concrete process involving abstract behaviors. |
Singleton | Uniqueness |
Null Object | Concept of "zero" (something that represents nothingness) |
Observer-observable | Decoupled communications from a single sender to multiple receivers. |
Decorator | Encapsulation barriers/indirection layers to intercept and modify processing paths. |
Flyweight | Resource pooling |
To look for design patterns in the problem is to look for the underlying CS prinicples that are driving it. The design patterns and the abstract notions that they represent comprise the "chunks" into which a problem is decomposed in order to understand it -- "Abstract decomposition"
© 2017 by Stephen Wong