An overview of the Mediator design pattern and its implementation in Dart and Flutter
Previously in the series, I analysed a behavioural design pattern that separates algorithms from the objects they operate on - Visitor. This time I would like to represent one another behavioural design pattern that lets you reduce dependencies between a set of interacting objects by decoupling the interaction logic from the objects and moving it to a dedicated controller - it is the Mediator.
An overview of the Visitor design pattern and its implementation in Dart and Flutter
In the last article, I analysed a behavioural design pattern that enables loose coupling between the sender of a request and its receiver - the Chain of Responsibility. In this article, I would like to analyse and implement another behavioural design pattern that lets you separate algorithms from the objects on which they operate - it is Visitor.
An overview of the Chain of Responsibility design pattern and its implementation in Dart and Flutter
Previously in the series, I analysed a structural design pattern that introduced a concept of a "shared object" which could be used in multiple contexts simultaneously, hence reducing the memory usage of your code - Flyweight. This time I would like to represent a behavioural design pattern, which enables loose coupling between the sender of a request and its receiver, also adding a possibility for the same request to be handled by multiple handlers - it is the Chain of Responsibility.
An overview of the Flyweight design pattern and its implementation in Dart and Flutter
In the last article, I analysed a creational design pattern that divides the construction of a complex object into several separate steps - Builder. In this article, I would like to analyse and implement a structural design pattern that helps using a huge number of objects in your code that could barely fit into available RAM - it is Flyweight.
An overview of the Builder design pattern and its implementation in Dart and Flutter
Previously in the series, I analysed a relatively complex, but very practical and useful structural design pattern — Bridge. This time I would like to represent a design pattern, which divides the construction of a complex object into several separate steps. It is a creational design pattern called Builder.
An overview of the Bridge design pattern and its implementation in Dart and Flutter
In the last article, I analysed a structural design pattern that provides a way of changing the skin of an object without changing its guts - Decorator. In this article, I would like to analyse and implement another structural design pattern that tends to be relatively difficult to understand compared to the other design patterns, but at the same time is practical and useful - it is Bridge.
An overview of the Decorator design pattern and its implementation in Dart and Flutter
Previously in the series, I analysed a relatively simple, but very practical design pattern — Proxy. This time I would like to represent a design pattern, that, unlike the Strategy design pattern, extends the functionality of an object instead of exchanging it. It is a structural design pattern called Decorator.
An overview of the Proxy design pattern and its implementation in Dart and Flutter
In the last article, I analysed a relatively simple design pattern compared to the other patterns in the series - Prototype. In this article, I would like to analyse and implement a structural design pattern that is very practical and could be used in a lot of cases when developing applications with Dart and Flutter - it is a Proxy.
An overview of the Prototype design pattern and its implementation in Dart and Flutter
Previously in the series, I analyzed one of the behavioural design patterns - Memento. This time I would like to represent a relatively simple design pattern compared to the other patterns in the series that belong to the category of creational design patterns - the Prototype.
An overview of the Memento design pattern and its implementation in Dart and Flutter
In the last article, I analysed a relatively popular design pattern - Command. In this article, I would like to analyse and implement a behavioural design pattern that works pretty well alongside the Command pattern - it is Memento.