Design Patterns Illustrated
100 likes42,856 views
The document discusses design patterns in object-oriented programming, highlighting their role in promoting code reuse and modularity. It categorizes patterns into creational, structural, and behavioral groups, providing examples like factory methods and the observer pattern. Additionally, it emphasizes key object-oriented principles such as encapsulation, single responsibility, and loose coupling.
Design Patterns Illustrated
- 1. Design Patterns illustrated Herman Peeren May 31st 2010 (DP-illustrations: Nelleke Verhoeff)
- 2. Design Patterns ●● recipes against common (OO-) programming problems ●● code reuse: no need to reinvent the wheel ●● common language ●● GOF: 23 “classical” patterns classic, The Book very nice!
- 3. The one constant in software development:
- 4. The one constant in software development: CHANGE!
- 5. The one constant in software development: CHANGE! I knew it ...
- 6. Ideal: code as modular black boxes
- 7. Wish list and OOP-principles ●● loose coupling: 1 change = ceteris paribus ●● code reuse (is not the same as copy/paste) ●● open for extension, closed for modification ●● encapsulate what varies ●● single responsibility principle ●● program against an interface not against an imple- mentation. Dependency injection ●● prefer composition over inheritance (in fact this is all the same with different words)
- 9. It might get you into trouble...
- 11. some code smells: 1.● duplicate code: DRY 2.● long method, huge class: SRP 3.● combinatorial explosion (similar classes) 4.● conditional complexity, switch statements 5.● “exhibitionistic” classes
- 12. some code smells: 1.● duplicate code: DRY 2.● long method, huge class: SRP 3.● combinatorial explosion (similar classes) 4.● conditional complexity, switch statements 5.● “exhibitionistic” classes
- 13. Classic pattern categories creational, structural and behavioral patterns: ●● creational: object instantiation ●● structural: larger structures of classes or objects ●● behavioral: interaction and distribution of responsibility
- 14. Creational design patterns ●● Factory Method: Allow subclasses to “decide” which class to instantiate. ●● Abstract Factory: Encapsulate a set of analo- gous factories that produce families of objects. ●● Builder: Encapsulate the construction of com- plex objects from their representation; so, the same building process can create various repre- sentations by specifying only type and content. ●● Singleton: Ensure that only a single instance of a class exists and provide a single method for gaining access to it. ●● Prototype: Create an initialized instance for cloning or copying.
- 15. Factory Method Provide an interface for the creation of objects. Allow subclasses to “decide” which class to instantiate. c
- 16. Abstract Factory Povide an interface for creating families of related or dependent objects. A factory for factories. c
- 17. Builder Seperate the construction process (how) of a complex object from the concrete representations (what). c
- 18. Singleton Ensure a class only has one instance, and provide a global point of access to it. Oh, I’m so loooooooonly c
- 19. Joomla! ●● JFactory: a class with static methods to instantiate objects like JDatabase, JUser, JDocument, JTemplate, etc. ●● most of those methods are singletons Nooku ●● KFactory: any class can be instantiated ●● get() = singleton, tmp() = any instantiation
- 20. “Every advantage has its disadvantages” (free to Johan Cruyff, Dutch Football Pattern Designer and Ajax-fan...)
- 21. Prototype Make variations on copies of a basic-object. COPY-SERVICE c
- 22. Structural design patterns ●● Adapter: Adapt an interface to an expected interface. ●● Bridge: Decouple an interface from its implementation. ●● Composite: Create a tree structure for part-whole hierarchies. ●● Decorator: Extend functionality dynamically. ●● Facade: Simplify usage by defining a high-level interface. ●● Flyweight: Support fine-grained objects efficiently by sharing. ●● Proxy: Represent an object with another object for access control.
- 23. Adapter (= Wrapper) c Adapt an interface to an expected interface.
- 24. Joomla! ●● new in 1.6: JAdapter and JAdapterInstance ●● JUpdateAdapter extends JAdapterInstance JUpdaterExtension & JUpdaterExtension extend JUpdateAdapter wanted: documentation and examples! what does it adapt?
- 25. Bridge Decouple an abstraction from its implementation. COLA 1 LITER 1 LITER COLA 1 LITER 1 LITER COLA MILK COLA MILK COLA MILK c
- 26. Composite Create a tree structure for part-whole hierarchies. A node is also a (part of a) tree. Recursive: c
- 27. Decorator Add extra functionallity (at runtime), while keeping the interface the same. Matroushka’s... c
- 28. Decorator Nooku ●● KPatternDecorator: a general decorator ●● e.g. extended by KDecoratorJoomlaApplication
- 29. Facade Provide a general (simpler) interface for a set of interfaces. looks simple c
- 30. Flyweight Use one instance of a class to provide many “virtual” instances. c
- 31. Proxy Provide a surrogate or placeholder for another object to control access to it. c
- 32. Behavioral design patterns ●● Chain of Responsibility: Define a method of passing a request among a chain of objects. ●● Command: Encapsulate a command request in an object. ●● Interpreter: Allow inclusion of language elements in an appli- cation. ●● Iterator: Enable sequential access to collection elements. ●● Mediator: Define simplified communication between classes. ●● Memento: Save and restore the internal state of an object. ●● Observer: Define a scheme for notifying objects of changes to another object. ●● State: Alter the behavior of an object when its state changes. ●● Strategy: Encapsulate an algorithm inside a class. ●● Template Method: Allow subclasses to redefine the steps of an algorithm. ●● Visitor: Define a new operation on a class without changing it.
- 33. Command Encapsulate a command request in an object. YOU,DO YOUR TASK! TASK TASK LIGHT LIGHT ON OFF c
- 34. Chain of Responsibility c Define a method of passing a request among a chain of objects.
- 35. Nooku ●● KCommandChain + KCommandContext, KCommandEvent, KCommandHandler and KCommandInterface ●● N.B.: executes a series of commands instead of passing a command to a series of handlers (like in Tapestry e.g.) ...correct me if I’m wrong....
- 36. Interpreter Domain -> (little) language -> grammar -> objects (DSL) HÉ! he means: do this, do that, and after finishing it, go there! c
- 37. Iterator Enable sequential access to collection elements, without showing the underlying data-structures (array, list, records, etc) next next c
- 38. Mediator c Layer in between: communication via one object.
- 39. Memento Save and restore the internal state of an object. ME c
- 40. Observer Notify “subscribers” of changes. ME NO ME ME WHO? c
- 41. Joomla! ●● JObserver and JObservable ●● JObserver extended by JEvent and that by JPlugin Nooku ●● KPatternObserver and KPatternObservable
- 42. State Let an object show other methods after a change of internal state (as if it changes it’s class). in a.....hick......different state, ....hick....I behave differently....hick..... c
- 43. Strategy When something can be done in several ways, make those ways interchangeable. POSSI- BILITIES c
- 45. Template Method The skeleton of an algorithm is fixed, but parts can be filled in differently. c
- 46. Visitor Make a kind of plugin-possibility for methods: in that way me- thods can be added in runtime. printservice! c
- 47. extra: Mixin ●● Used in Nooku (and a.o. in Ruby and Python) ●● a kind of abstract class that is mixed into another object ●● all methods of the mixin are now part of the object ●● handle with care: beware of tight coupling....
- 48. Golden OO-principles ●● encapsulate what varies, OCP ●● 1class, 1 responsibility, SRP ●● program against an interface, not against an imple- mentation, DIP ●● prefer composition over inheritance ●● loose coupling, modular black boxes
- 49. Some books GOF: 23 “classical” patterns: very nice! classic, The Book handy examples
- 50. good start Fowler: extended e.g. with patterns for web Fowler: also known from refactoring combi: re- factoring & patterns
- 51. Resign Patterns: Ailments of Unsuitable Project-Disoriented Software
- 52. Joomla! Could be improved by studying design patterns and applying them. Loose coupling...
- 53. Questions? Contact info: Herman Peeren [email protected] © Yepr The artwork in this presentation is provided under the Creative Commons Public License for noncommercial use. http://creativecommons.org/licenses/by-nc/3.0/legalcode