Official Design Patterns - herougo/SoftwareEngineerKnowledgeRepository GitHub Wiki
source (great explanations): https://refactoring.guru/design-patterns/
Creational Design Patterns
- Factory - e.g. multiple subclasses implement createButton, which return a type depending on that subclass
- Builder - e.g. have many optional parameters, but don't want tons of parameters passed
- e.g. building a deluxe pizza
- Prototype - i.e. clone method that works and doesn't require the coder to know the type (e.g. AbstractThing a = ...; AbstractThing b = ????(a);)
- Singleton
Structural Design Patterns
- Adapter - e.g. XML to JSON (making a square fit into a round hole)
- Bridge (abstraction and implementation; remote abstraction vs device implementation)
- Decorator
- Facade - simplifies the interface by wrapping around multiple modules (e.g. VideoConverter makes use of MPEG4CompressionCodec, AudioMixer, etc)
- Wrapper - makes an existing interface usable (e.g. Youtube API wrapper)
- Flyweight - store large, immutable data in has a (e.g. sprites)
- Proxy - (see diagram), owns a service; after the proxy finishes its processing (e.g., lazy initialization, logging, access control, caching, etc.), it passes the request to the service object.
Behavioural Design Patterns
- Chain-of-Responsibility - basically a linked list of Handlers (e.g. user verification, click handling of composition of UI objects)
- https://stackoverflow.com/questions/1055383/what-are-the-advantages-of-chain-of-responsibility-vs-lists-of-classes
- mentions that the CoR can handle pre-processing
- https://stackoverflow.com/questions/1055383/what-are-the-advantages-of-chain-of-responsibility-vs-lists-of-classes
- Command - e.g. mutiple buttons for saving -> implement SaveCommand
- Iterator
- Mediator - (see diagram), e.g. textbox shown dependent on checkbox
- Memento - (snapshots; see diagram) The originator has full access to the memento, whereas the caretaker can only access the metadata.
- Observer - subscriber/publisher model
- State - e.g. AudioPlayer states (ready, locked, playing) each implement clickPlay, clickStop (as opposed to switch statements)
- Strategy - e.g. route planner owns a WalkingStrategy or RoadStrategy
- very similar to the bridge pattern
- Template - essentially inheritance with default implementations provided by the superclass
- Visitor - (see diagram) ability to add new functionality to a class without modifying the class
- could just write a function which takes in the object as the first argument