Software Construction: Design Patterns 3
Cards to learn the design patterns
Cards to learn the design patterns
Kartei Details
| Karten | 9 |
|---|---|
| Sprache | Deutsch |
| Kategorie | Informatik |
| Stufe | Universität |
| Erstellt / Aktualisiert | 28.12.2019 / 10.01.2020 |
| Weblink |
https://card2brain.ch/box/20191228_software_construction_design_patterns_3
|
| Einbinden |
<iframe src="https://card2brain.ch/box/20191228_software_construction_design_patterns_3/embed" width="780" height="150" scrolling="no" frameborder="0"></iframe>
|
The Composite Pattern (Definition)
The Composite Pattern allows you to compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
The Class Diagram of Composite Pattern
Design Principles
- Identify the aspects of your application that vary and separate them from what stays the same
- Program to an interface, not to an implementation
- Favor composition over inheritance
- Classes should be open for extension, but closed for modification.
The Strategy Pattern (Definition)
The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
Example Class Diagram of Deck with Strategy Pattern
The Open-Closed Principle
Open: Feel free to extend our classes with any new behavior you like. If your needs or requirements change (and we know they will), just go ahead and make your own extensions.
Closed: We spent a lot of time getting this code correct and bug free, so we can’t let you alter the existing code. It must remain closed to modification.
The Decorator Pattern (Definition)
The Decorator Pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
The Class Diagram of Decorator Pattern
Inheritance vs Composition
- We are using inheritance to achieve the type matching, but we are not using inheritance to get behavior.
- We are acquiring new behavior not by inheriting it from a superclass, but by composing objects together.
- With composition, we can mix and match decorators any way we like at runtime.
- Traditionally the Decorator Pattern does specify an abstract component, but in Java, obviously, we could use an interface.
