Design - Design Patterns
About
-
It is a reusable solution to common problems in software design.
Behavioral Patterns
-
Definitions:
-
"Behavioral patterns are concerned with algorithms and the assignment of responsibilities between objects."
-
"Behavioral design patterns are design patterns that identify common communication patterns among objects. By doing so, these patterns increase flexibility in carrying out communication."
-
-
Direct and Indirect Communication Patterns
-
Strategy Pattern
-
It is the Component Pattern, that is, 'dependency injection'.
-
Creates an Interface with ('abstract methods' and 'virtual methods') (?).
-
Uses Composition, since the 'class' does not inherit from anywhere, it only asks for components, where those components are 'concrete classes' of the Interface.
-
-
He made use of Interfaces, which I did not understand the need for.
-
-
-
{16:58}
-
He shows that certain implementations of the Interface have duplicated code due to their similarity.
-
It is discussed how to solve the problem, but the idea is that "the solution to an Inheritance problem is not to add more Inheritance".
-
-
Observer Pattern
-
It is the Signal Emission pattern.
-
-
At the end of the video the code is shown demonstrating the functions and relations between the Observable and Observer.
-
-
-
{32:20}
-
He wraps up the reasoning well.
-
-
The use of signals is a good solution to separate objects that should not relate, but it is a bad solution when used on objects that should relate.
-
This all comes down to the question "what should be defined as an object and what should be defined as part of an object"? "where does your object begin and where does it end"?
-
State Pattern (State Machine)
-
It is the State Machine pattern.
-
A State Machine is nothing more than an 'if/else' or 'match', but for reasons of clarity and organization in a Component System style, states are extracted into different scripts, creating components that represent the States.
-
My notes on the topic : Game AI .
-
Considering that a State Machine is normally used to define AI, it makes more sense for the notes to be there.
-
Template Method Pattern
-
-
{41:53 -> 50:02} (only relevant part of the video)
-
-
It is similar to the Strategy Pattern.
-
Comparison between the Template Method Pattern and Strategy Pattern:
-
Template Method Pattern:
-
Creates an 'abstract class' with 'abstract methods' and 'virtual methods'.
-
Uses Inheritance, since the 'class' inherits from the 'abstract class'.
-
-
Strategy Pattern:
-
Creates an Interface with ('abstract methods' and 'virtual methods') (?).
-
Uses Composition, since the 'class' does not inherit from anywhere, it only asks for components, where those components are 'concrete classes' of the Interface.
-
-
-
Considering this, the Template Method Pattern makes a larger assumption of immutability, assuming the system will never change, making it somewhat unsafe in many cases.
-
For reasons like this, I choose not to use State Machines. I believe State Machines are by their nature a form of Template, which makes me quite wary about the code structure.
-
I made several criticisms about this when analyzing State Machines.
-
-
Chat GPT:
-
Template Method Pattern:
-
The Template Method pattern is intrinsically based on inheritance. It relies on the principle of a base class that defines the skeleton of an algorithm and allows subclasses to implement specific parts of that algorithm. Those specific parts are often implemented through abstract methods defined in the base class and implemented in subclasses. Therefore, inheritance is an essential part of implementing this design pattern.
-
-
Finite State Machines:
-
Implementing FSMs does not necessarily depend on inheritance. In many cases, states and transitions can be implemented without direct use of inheritance. Each state can be represented by a separate class, but that does not mean one class must inherit from another to represent different states. However, in some implementations it may be useful to use inheritance to share common behaviors between states, but this is not a strict requirement.
-
-
Null Object Pattern
-
It is very simple. The idea is that in some cases a check 'if object != null' is always performed, but the proposal is to make the object always exist, so it can never be 'null'; instead it will be a generic object that implements the interface but simply does nothing.
-
*Review:
-
Cool. Interesting.
-
It can be useful when an object uses Interface / Inheritance; otherwise the pattern is not applicable and does not make sense.
-
It is a nice way to remove the 'null' check using Subtype Polymorphism.
-
Command Pattern
-
It is a pattern for creating 'programmable buttons', outsourcing the command, etc.
-
The pattern is straightforward, but it definitely sounds like over-engineering for simple cases.
-
-
The example given is a "smart home remote control, where the remote's functions can be programmed by the phone".
-
-
*Review:
-
Very specific for creating buttons and perhaps ~over-engineering.
-
Iterator Pattern
-
-
Advantages:
-
"The collection does not have to expose its representation. Every time the collection is requested, one item of the collection will be given, without ever having to worry about or expose the 'shape' of that collection."
-
"There is always a pointer pointing to the next element of the iteration, so the iteration can stop at any time and continue from where it left off".
-
-
{59:54}
-
The UML diagram is shown, which helps to understand the relationship between Iterator and Iterable.
-
-
-
*Review:
-
Interesting, but quite specific.
-
Creational Patterns
-
Definitions:
-
"Creational patterns provide various object creation mechanisms, which increase flexibility and reuse of existing code."
-
"Creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or in added complexity to the design due to inflexibility in the creation procedures. Creational design patterns solve this problem by somehow controlling this object creation."
-
Dependency Injection
-
A design pattern where a class receives its dependencies from the outside, instead of creating them internally.
-
Reduces coupling between classes, making the code more flexible and testable.
-
Makes it easy to swap implementations without modifying the main class.
-
Without Subtype Polymorphism :
-
.
-
-
With Subtype Polymorphism :
-
.
-
Singleton Pattern
-
"The pattern ensures that the class has only one instance and provides a global access point to it".
-
-
The presenter warns against using this method, because it is problematic, etc.
-
Factory Method Pattern
-
The pattern is based on creating a method that governs how the instantiation of other objects will be done.
-
Different 'factories' can have different logic for instantiating objects.
-
-
He gave the example of "wanting to instantiate animals randomly in a forest".
-
-
*Review:
-
This pattern only makes sense in situations where you want to create an object but you don't exactly know which parameters govern the creation of that object, leaving that responsibility to the chosen 'factory'.
-
The pattern sounds useful but extremely specific to random generation, which makes it easy to forget.
-
Abstract Factory Pattern
-
It is very similar to the Factory Method, but it is based on creating multiple objects instead of single objects.
-
*Review:
-
Same review as the Factory Method Pattern.
-
Structural Patterns
-
Definitions:
-
"Structural design patterns explain how to assemble objects and classes into larger structures, while keeping these structures flexible and efficient."
-
"Structural design patterns are design patterns that ease the design by identifying a simple way to realize relationships among entities."
-
-
Comparison between Structural Patterns .
-
A comparison between Adapter, Facade, Proxy, Decorator and Bridge is made.
-
{1:42 -> 10:10}
-
Brief explanations of the patterns and UML drawings.
-
The rest of the video is just discussion about the drawings.
-
-
-
Comparison between Composite Pattern and Decorator Pattern .
-
Both use recursion and have a very similar UML diagram, with the difference that "the Decorator uses Abstractions in the definition of the Decorator, while the Composite uses Concretions" (nah, I didn't care enough about these methods to care).
-
"For a Decorator to be a Decorator, it needs to Decorate something, only one thing, to be specific. If you have a Decorator that decorates many things, you'll have a Composite Pattern, not a Decorator Pattern."
-
The idea is that if a "Decorator decorates many things", you create a Tree system.
-
-
Decorator Pattern
-
The pattern is based on "wrapping" an object in other objects to change the internal behavior at runtime.
-
-
{~28:30}
-
It becomes clearer what the idea of this pattern is: It uses a recursive system where the Wrapper calls what is inside it recursively, and at each interaction modifications are made to the final return of the function.
-
-
{37:00}
-
Code examples are shown, also helping a lot to understand the pattern.
-
-
{43:37}
-
It is shown how the coffee example used by the book is ultra over-engineering, being unnecessary and confusing; the presenter simply suggests using a list of ingredients and iterating the list.
-
-
-
*Review:
-
I did not like this pattern, it feels like over-engineering in many moments.
-
Adapter Pattern
-
Also known as a 'Simple Wrapper'.
-
Makes two incompatible interfaces compatible, just like a plug adapter.
-
*Review:
-
Useful only for cases of creating compatibility between two things, very specific.
-
Facade Pattern
-
Creates a "disguise" for complex interactions in the code to make interaction more friendly.
-
-
Implementation was not necessarily explained, just a discussion about the subject.
-
-
*Review:
-
It seems like a kind of 'macro' to communicate with complex things or to create complex things.
-
Its use is interesting, but it gives me the impression that if you have to use this kind of thing, the code is huge and messy.
-
Proxy Pattern
-
"Adds behaviour to an object, with the intent to control access to that object".
-
-
{24:09 -> 27:02}
-
The UML diagram is explained, showing the relationship between the Object, the Interface and the Proxy.
-
-
From what I understand, the Proxy implements the same Interface as the Object while also holding a reference to the Object. This allows the Proxy to control access to the Object if the function call is made through the Proxy.
-
The presenter says "it's like caching".
-
I did not understand why the Proxy must implement the Object's Interface.
-
-
-
*Review:
-
Seems useful for access control and greater control of the object, but I found the pattern a bit confusing due to the Proxy's use of the Interface.
-
Bridge Pattern
-
I did not understand this pattern very well.
-
The pattern seems to have a rather loose definition, kind of whatever.
-
*Review:
-
It seems to make a mess to ~fix communication between classes, apparently. It's a pattern that makes me question whether its use is only for cases where a design is poorly structured.
-
I didn't find anything useful, but maybe if I understood it better I would change my mind.
-
Composite Pattern
-
It is based on the idea of Root and Leaf, where a Root is something that has children and a Leaf is something that has no children.
-
In this context, it resembles the Decorator Pattern (and a bit the Strategy Pattern), since the entire Tree of a Root characterizes that Root, acting like a pseudo-wrap, reminding of the Decorator Pattern.
-
Although it sounds similar to a Finite State Machine, that is not actually the case, since a Root's children do not characterize 'states', but only characteristics of that Root, making it closer to the Strategy Pattern than a Finite State Machine.
-
-
The presenter spent most of the video discussing the 'add' and 'remove' functions of the components, discussing how this breaks the "Interface segregation principle".
-
The example used in the video is quite confusing, being an example of 'to-dos in html'.
-
-
*Review:
-
This pattern only makes sense to use when dealing with some hierarchical organization.
-
It is very similar to the Decorator, so since I didn't like the Decorator much, I didn't like this one much either.
-