35 posts tagged with "Dart"

Some insights on how to implement a production-quality app using Dart + Flutter

Recently, I received a task to build a shopping app prototype using Dart + Flutter. The main requirements were to use the real-world e-commerce API of free choice, implement lazy products' loading and caching, and build products and their details page. All the other implementation details were left up to me, hence I had to decide on the app architecture, state management solution, third-party packages, etc. So in this article, I will reflect on my choices, challenges and other details while implementing a production-quality prototype.

An overview of the Observer design pattern and its implementation in Dart and Flutter

In the last article, I analysed a behavioural design pattern that reduces dependencies between a set of interacting objects by decoupling the interaction logic from the objects and moving it to a dedicated controller - Mediator. In this article, I would like to analyse and implement another behavioural design pattern that lets you define a publish-subscribe mechanism to notify multiple objects about any events that happen to the object they're subscribed to - it is Observer.

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.