DEV Community: Mangirdas Kazlauskas 🚀

23 - Observer

Mangirdas Kazlauskas 🚀 — Mon, 21 Jun 2021 10:23:29 +0000

In the last article, I have 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.

What is the Observer design pattern?
Analysis
Implementation
Your Contribution

What is the Observer design pattern?

Observer, also known as Dependents or Publish-Subscribe, belongs to the category of behavioural design patterns. The intention of this design pattern is described in the GoF book:

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

Spoiler alert: if you have ever heard about reactive programming or even used the related frameworks/libraries/tools such as ReactiveX, RxDart or just basic streams in Dart, this design pattern won’t be a game-changer to you. But it is still worth knowing how reactive programming ideas are implemented in the OOP context from the ground up, though.

The motivation for this design pattern comes from the problem of having a collection of tightly coupled objects in the system where changes for one object should trigger changes in the others (one-to-many relationship). An inflexible way to implement this is to define an object that implements updating the state of other dependent ones. Such object becomes hard to implement, maintain, test and reuse because of the dependency chaos.

A better way to approach this is to implement a publish-subscribe mechanism that sends the update events to dependent objects so they could implement and maintain the update logic on their own. To achieve this, the Observer design pattern introduces two roles: Subject and Observer.

The subject is the publisher of notifications that also defines a way for the observers to subscribe/unsubscribe from those notifications. A subject may have any number of dependent observers — the same idea of maintaining a one-to-many relationship just in a more flexible way. When a subject changes state, all registered observers are notified and updated automatically. This way the subject could trigger an update on dependent objects without even knowing who its observers are — this enables loose coupling between subject and observers.

Let’s move to the analysis and implementation parts to understand and learn the details about this pattern and how to implement it!

Analysis

The general structure of the Observer design pattern looks like this:

Publisher (Subject) — provides an interface for attaching and detaching Subscriber (Observer) objects, contains a list of observers;
(Optional) Concrete Publishers — stores state of interest for Concrete Subscribers and sends a notification to its observers when the state changes. This class is optional when only a single type of Publisher is needed. In such case, the state and notification logic is handled by the Publisher;
Subscriber (Observer) — declares the notification interface for objects that should be notified of changes in a Subject;
Concrete Subscribers — implements the Subscriber (Observer) interface to keep its state consistent with the subject’s state;
Client — creates Subject and Observer objects, attaches observers to subject updates.

Observer vs Mediator

If you have read the previous article in the series or are familiar with the Mediator design pattern you could feel some kind of déjà vu — isn’t the Observer design pattern the same thing? Let me explain.

The primary goal of the Mediator design pattern is to replace many-to-many relationships between objects with one-to-many relationship by using the dedicated mediator object that handles the communication part. Observer allows establishing a dynamic one-way connection between objects, where some objects act as subordinates of others.

If you have only one mediator that allows subscriptions to its state, this implementation is based on the Observer design pattern but the Mediator design pattern could be also used only as a part of the publish-subscribe communication. Now, if we have multiple publishers and multiple subscribers (which could be publishers as well), there won’t be any mediator object only a distributed set of observers.

Applicability

The Observer design pattern should be used when a change to one object requires changing others, but you don’t know how many objects need to be changed and how. The pattern allows subscribing to such object events and changing the dependent object’s state accordingly.

Also, this pattern should be used when some objects must observe others, but only for a limited time. The subscription mechanism allows dependent objects to listen to the update events on demand and change this behaviour at run-time.

Implementation

For the implementation part, we will use the Observer design pattern to implement a stock market prototype.

In the stock market, there are hundreds and thousands of different stocks. Of course, not all of them are relevant to you, so you would like to subscribe and track only the specific ones.

The prototype allows subscribing to 3 different stocks — GameStop (GME), Alphabet Inc. a.k.a. Google (GOOGL) and Tesla Motors (TSLA). Also, there are two different types of subscriptions:

Default stock subscription — notifies about every subscribed stock change.
Growing stock subscription — notifies only about the growing stock changes.

Such stocks’ tracker could be easily implemented by using the Observer design pattern. Of course, the prototype only supports 3 different stock types, but new stock tickers or even new subscription types could be easily added later on without affecting the existing code. Let’s check the class diagram first and then implement the pattern!

Class diagram

The class diagram below shows the implementation of the Observer design pattern:

StockTicker is an abstract class that is used as a base class for all the specific stock ticker classes. The class contains title, stockTimer and stock properties, subscribers list, provides several methods:

subscribe() — subscribes to the stock ticker;
unsubscribe() — unsubscribes from the stock ticker;
notifySubscribers() — notifies subscribers about the stock change;
setStock() — sets stock value;
stopTicker() — stops ticker emitting stock events.

GameStopStockTicker, GoogleStockTicker and TeslaStockTicker are concrete stock ticker classes that extend the abstract class StockTicker.

Stock class contains symbol, changeDirection, price and changeAmount properties to store info about the stock.

StockTickerSymbol is an enumerator class defining supported stock ticker symbols — GME, GOOGL and TSLA.

StockChangeDirection is an enumerator class defining stock change directions — growing and falling.

StockSubscriber is an abstract class that is used as a base class for all the specific stock subscriber classes. The class contains title, id and stockStreamController properties, stockStream getter and defines the abstract update() method to update subscriber state.

DefaultStockSubscriber and GrowingStockSubscriber are concrete stock subscriber classes that extend the abstract class StockSubscriber.

StockTicker

An abstract class implementing base methods for all the specific stock ticker classes. Property title is used in the UI for stock ticker selection, stockTimer periodically emits a new stock value that is stored in the stock property by using the setStock() method. The class also stores a list of stock subscribers that can subscribe to the stock ticker and unsubscribe from it by using the subscribe() and unsubscribe() respectively. Stock ticker subscribers are notified about the value change by calling the notifySubscribers() method. The stock timer could be stopped by calling the stopTicker() method.

Concrete stock ticker classes

All of the specific stock ticker classes extend the abstract StockTicker class.

GameStopStockTicker — a stock ticker of the GameStop stocks that emits a new stock event every 2 seconds.

TeslaStockTicker — a stock ticker of the Tesla stocks that emits a new stock event every 3 seconds.

GoogleStockTicker — a stock ticker of the Google stocks that emits a new stock event every 5 seconds.

Stock

A simple class to store information about the stock. Stock class contains data about the stocker ticker symbol, stock change direction, current price and the change amount.

StockTickerSymbol

A special kind of class — enumeration — to define supported stock ticker symbols. Also, there is a StockTickerSymbolExtension defined where the toShortString() method returns a short version of the enumeration string value.

StockChangeDirection

A special kind of class — enumeration — to define stock change directions.

StockSubscriber

An abstract class containing base properties for all the specific stock ticker classes. Property title is used in the UI for stock subscriber selection, id uniquely identifies the subscriber. Updated stock values are added to the stockStreamController and emitted via the stockStream. Abstract method update() is defined and must be implemented by all the concrete stock subscriber classes.

Concrete stock subscriber classes

DefaultStockSubscriber — a default stock subscriber that emits every stock change on update.

GrowingStockSubscriber — a growing stock subscriber that emits only growing stock changes on update.

Example

First of all, a markdown file is prepared and provided as a pattern’s description:

ObserverExample contains a list of StockSubscriber as well as a list of StockTickerModel objects (specific StockTicker class with a flag of whether the user is subscribed to the stock ticker or not).

A specific subscriber class could be easily changed by using the StockSubscriberSelection widget. Also, StockTickerSelection allows easily subscribe/unsubscribe from the specific stock ticker at run-time.

As you can see in the example, the subscription type could be easily changed at run-time, you could start and stop tracking of the specific stocks at any point as well.

All of the code changes for the Observer design pattern and its example implementation could be found here.

Your Contribution

💖 or 🦄 this article to show your support and motivate me to write better!
💬 Leave a response to this article by providing your insights, comments or wishes for the next topic.
📢 Share this article with your friends, colleagues on social media.
➕ Follow me on dev.to or any other social media platform.
⭐ Star the Github repository.

22 - Mediator

Mangirdas Kazlauskas 🚀 — Mon, 14 Jun 2021 06:27:49 +0000

Previously in the series, I have analysed a behavioural design pattern that separates algorithms from the objects they operate on — Visitor. This time I would like to represent once 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.

What is the Mediator design pattern?
Analysis
Implementation
Your Contribution

What is the Mediator design pattern?

Mediator, also known as Intermediary or Controller, is a behavioural design pattern, which intention in the GoF book is described like this:

Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.

TL;DR: the main target of the Mediator design pattern is to move from the communicating object dependencies chaos provided on the left to the decoupled one provided on the right:

In the Mediator design pattern context, communicating objects are called colleagues while the object that controls and coordinates the interaction is called *drums rolls* the mediator.

The mediator is like a telephone exchange that keeps references to interacting objects and maintains all the required logic to “connect” colleague A with colleague B. As a result, colleague objects have no explicit knowledge of each other, they only refer to their mediator — in the OOP world, we could say that objects are loosely coupled. This allows reusing individual colleague objects independently since they have fewer dependencies on the other objects.

Another upside of the Mediator design pattern is that it simplifies and abstracts the way of how objects interact. First of all, the mediator replaces many-to-many (N:M) relationships with one-to-many (1:N) interactions between the mediator and its colleagues. In general, 1:N relationships are just easier to understand and maintain. Besides, the mediator object abstracts the interaction logic — colleagues should be aware only of the communication act but not of any details on how it is implemented. This abstraction enables adding new mediators without changing the actual components. Also, having the whole communication logic in a single place helps a lot when you need to adjust or maintain it.

Let’s just jump right in by analysing the Mediator design pattern and its implementation in more detail!

Analysis

The general structure of the Mediator design pattern looks like this:

Mediator — defines an interface for communicating with components;
ConcreteMediator — encapsulates relations between components by containing references to them;
(Optional) Abstract Component or Component Interface — similar communicating components could implement the same interface or extend the same base class. In this case, ConcreteMediator could store a list of components extending/implementing this class instead of keeping multiple references as separate properties;
Concrete component or Colleague — contains a reference to a mediator. Each colleague communicates with its mediator whenever it would have otherwise communicated with another colleague (component).

Applicability

The Mediator design pattern should be used when instead of having tightly coupled classes you want to have loose-coupled ones, because:

a) You want to reuse the component elsewhere. When a component is too dependent on other classes, it’s hard to reuse it as a stand-alone object.
b) You want to make changes in some of the classes, but they affect other dependencies. By using the Mediator design pattern, the relationship logic between objects is extracted to a separate class, hence the changes could be implemented without directly affecting the rest of the components.

Also, you should consider using the Mediator design pattern when there is a need to add communicating objects at run-time. Since the mediator class takes care of the communication logic and all the dependencies between objects, it’s possible to add or remove those dependencies later from the code just like adding a new user to the chat room.

However, by moving all the communication logic to a dedicated class there is a risk to end up having a God Object. To avoid this, make sure that the mediator class is only responsible for the communication part. If you notice any other calculations, data manipulations or extraneous operations (Eminem would be proud of this line, I think) they should be extracted to a dedicated class.

Implementation

We will use the Mediator design pattern to implement a notification hub for the engineering team.

Let’s say that we want a solution to send notifications to other team members. Inside the team, there are 3 main roles: Admin a.k.a. God, Developer and tester (QA engineer). There are times when the admin wants to send notifications to the whole team or members of a specific role. Also, any other team member should be able to send a quick note to the whole team, too.

If you think of this problem, you could quickly notice a many-to-many relationship between team members — every engineer should be aware of the others just to send the notification. For this reason, we will implement a centralised way to send notifications — a notification hub. You could think of it as a chat room — every team member joins the hub and later they use it to send notifications by simply calling a send method. Then, the hub distributes the message to the others — to all of them or by specific role.

By using this solution, team members should not be aware of the others, they are completely decoupled. Also, in the case of a new team member, it is enough to add him/her to the notification hub and you could be sure that all the notifications would be delivered.

Sounds too good to be true? Watch and learn!

Class diagram

The class diagram below shows the implementation of the Mediator design pattern:

TeamMember is an abstract class that is used as a base class for all the specific team member classes. The class contains name, lastNotification and notificationHub properties, provides several methods:

receive() — receives the notification from the notification hub;
send() — sends a notification;
sendTo() — sends a notification to specific team members.

Admin, Developer and Tester are concrete team member classes that extend the abstract class TeamMember as well as override the default toString() method.

NotificationHub is an abstract class that is used as a base class for all the specific notification hubs and defines several abstract methods:

getTeamMembers() — returns a list of team members of the hub;
register() — registers a team member to the hub;
send() — sends a notification to registered team members;
sendTo() — sends a notification to specific registered team members.

TeamNotificationHub is a concrete notification hub that extends the abstract class NotificationHub and implements its abstract methods. Also, this class contain a list of registered team members — teamMembers.

MediatorExample initialises and contains a notification hub property to send and receive notifications, register team members to the hub.

TeamMember

An abstract class implementing base methods for all the specific team member classes. Method receive() sets the lastNotification value, send() and sendTo() methods send notification by using the corresponding notificationHub methods.

Concrete team member classes

All of the specific team member classes extend the TeamMember and override the default toString() method.

Admin — a team member class representing the admin role.

Developer — a team member class representing the developer role.

Tester — a team member class representing the tester (QA) role.

NotificationHub

An abstract class that defines abstract methods to be implemented by specific notification hub classes. Method getTeamMembers() returns a list of registered team members to the hub, register() registers a new member to the hub. Method send() sends the notification to all the registered team members to the hub (excluding sender) while sendTo() sends the notification to team members of a specific type (excluding sender).

TeamNotificationHub

A specific notification hub implementing abstract NotificationHub methods. The class also contains private teamMembers property — a list of registered team members to the hub.

Example

First of all, a markdown file is prepared and provided as a pattern’s description:

The MediatorExample widget initialises the TeamNotificationHub and later uses it to send notifications between team members.

Specific team members do not contain any reference about the others, they are completely decoupled. For communication, the notification hub is used that handles all the necessary logic to send and receive notifications from the team.

As you can see in the example, you could send notifications from different team members, add new members later to the hub so they will be notified, too.

All of the code changes for the Mediator design pattern and its example implementation could be found here.

Your Contribution

21 - Visitor

Mangirdas Kazlauskas 🚀 — Mon, 07 Jun 2021 06:12:24 +0000

In the last article, I have analysed a behavioural design pattern that enables loose coupling between the sender of a request and its receiver — 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.

What is the Visitor design pattern?
Analysis
Implementation
Your Contribution

What is the Visitor design pattern?

Visitor belongs to the category of behavioural design patterns. The intention of this design pattern is described in the GoF book:

Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

Let’s say we have a complex object structure, maybe it is a tree or collection, that consists of several different class components. Now, we want to add some kind of new functionality to these components without changing the classes themselves — is that even possible?

The key idea here is to define a double-dispatch operation (in the Visitor design pattern’s context, the operation is called accept) for each specific complex object class — I know, you could think that I lied to you about adding new operations without changing the existing code, but wait, there is a good reason for that! When clients traverse the object structure, the accept method is called on each element to delegate the request to the specific visitor object, which is passed to the method as a parameter. Then, the specific method of the visitor object is called (the request is delegated), hence performing the actual request. That’s the main idea of a double-dispatch operation — the client sends the request to the component, while the component delegates the request to the specific visitor’s method. It means, that it is enough to implement a single method to the component class and then you can define a new operation over an object structure simply by adding a new visitor. And this time, you could implement as many different visitor classes as you want without changing the existing code! How cool is that?

Also, the Visitor design pattern allows gathering related operations into a single class without spreading the implementation details across the whole object structure. That helps when you want to accumulate state while traversing an object structure — there is no need to pass the state to operations that perform the accumulation since the state is stored in the visitor object itself and is accessible by all the specific visitor methods.

At first, all the visitor, accept, double-dispatch terms could look confusing — don’t worry, it gets much clearer when you see the Visitor design pattern in action. Let’s move to the analysis and implementation parts to understand and learn the details about this pattern and how to implement it!

Analysis

The general structure of the Visitor design pattern looks like this:

Visitor — declares a visit operation for each concrete element class in the object structure. If the programming language supports function overloading, visit operations could have the same name (Dart does not support that at the moment), but the type of their parameters must be different. Usually, the operation’s name and signature is different and identifies the class (concrete element) that sends the visit request to the visitor;
Concrete visitors — implements each operation declared by Visitor;
Element — declares an accept method that takes Visitor as an argument;
Concrete elements — implements the acceptance method. The implementation should rely on redirecting the request to the proper visitor’s method corresponding to the current element class;
Client — usually contains a collection or a complex object structure, initialises the concrete visitor object and then traverses the object structure by visiting each element with the visitor.

Applicability

The primary purpose of the Visitor design pattern is to separate algorithms from the objects on which they operate, hence cleaning up the business logic. This way, the classes of your app could focus on their main job while auxiliary behaviours are extracted into a set of visitor classes. Also, visitors allows keeping the related operations together by defining them in one class.

Furthermore, the Visitor design pattern should be used when you want to execute an operation on all elements of a complex object structure and you do not want to change the interface(s) of concrete classes. Different visiting method implementations are executed on different classes which accept the visitors, hence the specific implementation details could be changed or new specific visitor implementations could be added without interfering with the existing code base of the object structure and its components.

Finally, there is one important thing to note: the Visitor design pattern only makes sense for object structures that rarely change (as always, take it with a grain of salt). If you just want to change or add new implementations of visitor — that’s fine. However, changing the object structure classes requires redefining the interface to all visitors which could become cumbersome and violates the Open-Closed (the letter O in SOLID principles). A simple solution to this problem is just defining the operations in those classes without extracting them to a visitor.

Implementation

For the implementation part, we will use the Visitor design pattern on the already implemented complex object structure which was introduced with the Composite design pattern. In my opinion, it would be a great example of how different design patterns could complement each other and how to reuse/extend the already existing codebase.

Our complex object structure is a file system that consists of directories and files of various types (audio, video, text, etc.). Let’s say that this kind of structure is already implemented using the Composite design pattern. Now, we want to add a possibility to export such file structure in two different formats: human-readable (just provide each file in a single, formatted list) and XML.

The first possible approach to implement this feature is to define the export method for each specific file type. In this case, this is wrong for several reasons:

For each specific export option, we would need to implement a separate export method in each specific file class. Also, by adding a new export option in the future, we would need to add some extra code to each file class once again.
It’s a violation of the Single-responsibility principle. The export functionality is just an auxiliary operation applied on top of the file structure, hence each specific file should not care and store the implementation details inside the class itself.

As you could guess, these problems could be easily resolved by applying the Visitor design pattern and defining each specific export option in a separate visitor class which takes care of all the specific implementation details for all the file types in a single place. Let’s check the class diagram first and then implement the pattern!

Class diagram

The class diagram below shows the implementation of the Visitor design pattern:

IFile defines a common interface for both File and Directory classes:

getSize() — returns the size of the file;
render() — renders the component’s UI;
accept() — delegates request to a visitor.

File class implements the getSize() and render() methods, additionally contains title, fileExtension, size and icon properties.

AudioFile, ImageFile, TextFile and VideoFile are concrete file classes implementing the accept() method from IFile interface and containing some additional information about the specific file.

Directory implements the same required methods as File, but it also contains title, level, isInitiallyExpanded properties and files list, containing the IFile objects. It also defines the addFile() method, which allows adding IFile objects to the directory (files list). Similarly as in specific file classes, accept() method is implemented here as well.

IVisitor defines a common interface for the specific visitor classes:

getTitle() — returns the title of the visitor that is used in the UI;
visitDirectory() — defines a visiting method for the Directory class;
visitAudioFile() — defines a visiting method for the AudioFile class;
visitImageFile() — defines a visiting method for the ImageFile class;
visitTextFile() — defines a visiting method for the TextFile class;
visitVideoFile() — defines a visiting method for the VideoFile class.

HumanReadableVisitor and XmlVisitor are concrete visitor classes that implement visit methods for each specific file type.

VisitorExample contains a list of visitors implementing the IVisitor interface and the composite file structure. The selected visitor is used to format the visible files structure as text and provide it to the UI.

IFile

An interface that defines methods to be implemented by specific files and directories. The interface also defines an accept() method which is used for the Visitor design pattern implementation. Dart language does not support the interface as a class type, so we define an interface by creating an abstract class and providing a method header (name, return type, parameters) without the default implementation.

File

A concrete implementation of the IFile interface. In File class, getSize() method simply returns the file size, render() — returns the file’s UI widget which is used in the example screen.

Concrete file classes

All of the specific file type classes implement the accept() method that delegates request to the specific visitor’s method.

AudioFile — a specific file class representing the audio file type that contains an additional albumTitle property.

ImageFile — a specific file class representing the image file type that contains an additional resolution property.

TextFile — a specific file class representing the text file type that contains an additional content property.

VideoFile — a specific file class representing the video file type that contains an additional directedBy property.

Formatting extensions

Defines an extension method indentAndAddNewLine that adds nTab tabs at the beginning and a new line symbol at the end of a String.

IVisitor

An interface that defines methods to be implemented by all specific visitors.

Concrete visitors

HumanReadableVisitor — implements the specific visitor that provides file information of each file type in a human-readable format.

XmlVisitor — implements the specific visitor that provides file information of each file type in XML format.

Example

First of all, a markdown file is prepared and provided as a pattern’s description:

The VisitorExample widget contains the buildMediaDirectory() method which builds the file structure for the example. Also, it contains a list of different visitors and provides it to the FilesVisitorSelection widget where the index of a specific visitor is selected by triggering the setSelectedVisitorIndex() method.

When exporting files’ information and providing it in the modal via the showFilesDialog() method, the example widget does not care about the concrete selected visitor as long as it implements the IVisitor interface. The selected visitor is just applied to the whole file structure by passing it as a parameter to the accept() method, hence retrieving the formatted files’ structure as text and providing it to the opened FilesDialog modal.

As you can see in the example, by selecting the specific visitor (export as text or XML option), the file structure is exported in the corresponding text format and provided to the user.

All of the code changes for the Visitor design pattern and its example implementation could be found here.

Your Contribution

20 - Chain of Responsibility

Mangirdas Kazlauskas 🚀 — Mon, 31 May 2021 07:32:38 +0000

Previously in the series, I have 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.

What is the Chain of Responsibility design pattern?
Analysis
Implementation
Your Contribution

What is the Chain of Responsibility design pattern?

Chain of Responsibility (CoR), also known as Chain of Command, is a behavioural design pattern, which intention in the GoF book is described like this:

Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.

TL;DR: the Chain of Responsibility design pattern is an ordered list of message handlers that know how to do two things — process a specific type of message or pass the message along to the next message handler.

First of all, the Chain of Responsibility design pattern is behavioural which means that its primary purpose is to rework the basic workflow (behaviour) and split it into several separate parts or stand-alone objects (recall Command or State design patterns as examples). Let’s say you have some kind of workflow defined in your code where each step should be executed sequentially. It works and everything is fine until…

Some additional steps should be introduced. Ok, not a big deal, just add them.
Some of these steps are optional based on the request. Well, let’s add some conditional blocks, nothing extraordinary.
Oops, we forgot validation… Hmm, the code starts bloating somehow.
A wild feature request appears: the order of the steps is different based on the request. Please, stahp…

Well, I hope you get the idea that this code could easily become a mess (not to mention the violation of the Open-Closed Principle — the letter O in SOLID principles). What the CoR pattern suggests is to split each step into a separate component — handler — and later link these handlers into a chain. Each handler contains a reference to the next one, hence once the request is received it is processed by the handler and passed to the next one along the chain until the workflow is finished. As a result, we still have the same sequential code execution, but now each step is separated, additional steps could be added without changing the existing code. But wait, there is more!

The Chain of Responsibility pattern allows reordering, adding or removing handlers in the chain at run-time — how cool is that, right? Also, each handler could be implemented in a way that it could decide whether to pass the request further down the chain or not.

Lots of great ideas already mentioned here, so let’s just jump right in by analysing the CoR design pattern and its implementation in more detail!

Analysis

The general structure of the Chain of Responsibility design pattern looks like this:

Handler — defines an interface for handling requests. This interface is optional when all the handlers extend the BaseHandler class — then having a single abstract method for handling requests should be enough;
BaseHandler — an abstract class that contains the boilerplate code that’s common to all the handler classes and maintains a reference to the next handler object on the chain. Also, the class may implement the default handling behaviour e.g. it can pass the request to the next handler if there is one;
ConcreteHandlers — contain the actual code for processing the request. Upon receiving a request, the handler could either handle it or pass it along the chain. Usually, handlers are immutable once they are initialised;
Client — composes the chain(s) of handlers and later initiates the request to a ConcreteHandler object on the chain.

Applicability

The Chain of Responsibility design pattern should be used when the system is expected to process different kinds of requests in various ways, but neither the request types nor the handling sequence is defined at compile-time. The pattern enables linking several handlers into one chain and allowing the client to pass requests along that chain. As a result, each handler will receive the request and process it and/or pass it further. Also, to resolve the unknown handling sequence problem, handlers could provide setters for a reference field of the successor inside the handler classes — you will be able to add, delete or reorder handlers at run-time, hence changing the handling sequence of a request.

Furthermore, the CoR pattern should be used when a single request must be handled by multiple handlers, usually in a particular order. In this case, the chain could be defined at compile-time and all requests will get through the chain exactly as planned. If the execution order is irrelevant, just roll the dice and build the chain in random order — all handlers would still receive the request and handle it.

Finally, one thing to remember — the receipt isn’t guaranteed. Since CoR introduces the loose coupling between sender and receiver, and the request could be handled by any handler in the chain, there is no guarantee that it will be actually handled. In cases when the request must be processed by at least one handler, you must ensure that the chain is configured properly, for instance, by adding some kind of a monitor handler at the end of the chain that notifies about unhandled requests and/or executes some specific logic.

Implementation

We will use the Chain of Responsibility design pattern to implement a custom logging workflow in the application.

Let’s say that we want 3 different log levels based on their importance:

Debug — only needed in the local environment for development purposes;
Info — we want to see those logs locally, but also they should be stored and visible in the external logging service when the application is deployed;
Error — those logs must be visible locally and external logging service, but also we want to notify our development team by sending an e-mail when such log appears.

In this case, our request is a log message with its content and log level. Our handlers — debug, info and error loggers with their custom logic. To implement the wanted workflow, we could link the loggers in the following order: Debug -> Info -> Error. If the logger’s log level is lower or equal to the one defined in the message, the message should be logged. And that’s basically it, really, it’s that simple!

A picture is worth a thousand words, so let’s check the class diagram first and then implement the pattern.

Class diagram

The class diagram below shows the implementation of the Chain of Responsibility design pattern:

The LogLevel is an enumerator class defining possible log levels — Debug, Info and Error.

LogMessage class is used to store information about the log message: its log level and the message text. It also provides a public getFormattedMessage() method to format the log entry as a Widget object (for that, a private helper method getLogEntryColor() and a getter logLevelString are used).

LoggerBase is an abstract class that is used as a base class for all the specific loggers:

logMessage() — logs message using the log() method and passes the request along the chain;
logDebug() — logs the message with a log level of Debug;
logInfo() — logs the message with a log level of Info;
logError() — logs the message with a log level of Error;
log() — an abstract method to log the message (must be implemented by a specific logger).

Also, the LoggerBase contains a reference to the next logger (nextLogger) and logger’s log level (logLevel).

DebugLogger, InfoLogger and ErrorLogger are concrete logger classes that extend the LoggerBase class and implement the abstract log() method. InfoLogger uses the ExternalLoggingService to log messages, ErrorLogger — the MailService.

All the specific loggers use or inject the LogBloc class to mock the actual logging and provide log entries to the UI.

LogBloc stores a list of logs and exposes them through the stream — outLogStream. Also, it defines the log() method to add a new log to the list and notify outLogStream subscribers with an updated log entries list.

ChainOfResponsibilityExample creates a chain of loggers and uses public methods defined in LoggerBase to log messages. It also initialises and contains the LogBloc instance to store log entries and later show them in the UI.

LogLevel

A special kind of class — enumeration — to define different log levels. Also, there is a LogLevelExtensions defined where the operator <= is overridden to compare whether one log level is lower or equal to the other.

LogMessage

A simple class to store information about the log entry: log level and message. Also, this class defines a private getter logLevelString to return the text representation of a specific log level and a private method getLogEntryColor() to return the log entry colour based on the log level. The getFormattedMessage() method returns the formatted log entry as a Text widget which is used in the UI.

LogBloc

A Business Logic component (BLoC) class to store log messages and provide them to the UI through a public stream. New log entries are added to the logs list via the log() method while all the logs could be accessed through the public outLogStream.

ExternalLoggingService

A simple class that represents the actual external logging service. Instead of sending the log message to some kind of 3rd party logging service (which, in fact, could be called in the logMessage() method), it just logs the message to UI through the LogBloc.

MailService

A simple class that represents the actual mail logging service. Instead of sending the log message as an email to the user, it just logs the message to UI through the LogBloc.

LoggerBase

An abstract class for the base logger implementation. It stores the log level and a reference (successor) to the next logger in the chain. Also, the class implements a common logMessage() method that logs the message if its log level is lower than the current logger’s and then forwards the message to the successor (if there is one). The abstract log() method must be implemented by specific loggers extending the LoggerBase class.

Concrete loggers

DebugLogger — a specific implementation of the logger that sets the log level to Debug and simply logs the message to UI through the LogBloc.

InfoLogger — a specific implementation of the logger that sets the log level to Info and uses the ExternalLoggingService to log the message.

ErrorLogger — a specific implementation of the logger that sets the log level to Error and uses the MailService to log the message.

Example

First of all, a markdown file is prepared and provided as a pattern’s description:

The ChainOfResponsibilityExample widget initialises and contains the loggers’ chain object (see the initState() method). Also, for demonstration purposes, the LogBloc object is initialised there, too, and used to send logs and retrieve a list of them through the stream — outLogStream.

By creating a chain of loggers, the client — ChainOfResponsibilityExample widget — does not care about the details on which specific logger should handle the log entry, it just passes (logs) the message to a chain of loggers. This way, the sender (client) and receiver (logger) are decoupled, the loggers’ chain itself could be built at run-time in any order or structure e.g. you can skip the Debug logger for non-local environments and only use the Info -> Error chain.

As you can see in the example, debug level logs are only handled by the debug logger, info — by debug and info level handlers and error logs are handled by all three loggers.

All of the code changes for the Chain of Responsibility design pattern and its example implementation could be found here.

Your Contribution

19 - Flyweight

Mangirdas Kazlauskas 🚀 — Mon, 24 May 2021 06:47:29 +0000

In the last article, I have 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.

What is the Flyweight design pattern?
Analysis
Implementation
Your Contribution

What is the Flyweight design pattern?

Flyweight belongs to the category of structural design patterns. The intention of this design pattern is described in the GoF book:

Use sharing to support large numbers of fine-grained objects efficiently.

Let’s take an object-oriented document editor as an example. For document elements like tables, images or figures, separate objects are created. However, for text elements (individual characters) this is not feasible even though it promotes flexibility: characters and any other embedded elements could be treated uniformly, the application could be extended to support new character sets very easily. The reason is simple — limitations of the hardware. Usually, a document contains hundreds of thousands of character objects which would consume a lot of memory and it could lead to unexpected crashes, for instance, when the document is being edited and eventually there would be no memory left for new characters or any other type of embedded objects. How this kind of object-oriented document editors could be implemented, then?

The “secret” relies on the flyweight objects — shared objects that can be used in multiple contexts simultaneously. But how this could even work? If we reuse the same object, doesn’t that mean that when the object is changed in one place, all the other places are affected, too? Well, the key concept here is the distinction between intrinsic and extrinsic state. The intrinsic state is invariant (context-independent) and therefore can be shared e.g. the code of a character in the used character set. The extrinsic state is variant (context-dependent) and therefore can not be shared e.g. the position of a character in the document. And that’s the reason why this concept works in object-oriented editors — a separate flyweight object is created for each character in the set (e.g. each letter in the alphabet) which stores the character code as the intrinsic state, while the coordinate positions in the document of that character are passed to the flyweight object as an extrinsic state. As a result, only one flyweight object instance per character could be stored in the memory and shared across different contexts in the document structure. Sharing is caring, right?

Let’s move to the analysis and implementation parts to understand and learn the details about this pattern and how to implement it!

Analysis

The general structure of the Flyweight design pattern looks like this:

Flyweight — contains intrinsic state while the extrinsic state is passed to the flyweight’s methods. The object must be shareable (can be used in many different contexts);
FlyweightFactory — creates and manages flyweight objects. When a client calls the factory, it checks whether the specific flyweight object exists. If yes, it is simply returned to the client, otherwise, a new instance of the flyweight object is created and then returned;
Context — contains the extrinsic state, unique across all original objects;
Client — computes or stores the extrinsic state of flyweight(s) and maintains a reference to it/them.

Applicability

The Flyweight design pattern should be used only when your program must support a huge number of objects which barely fit into available RAM. The pattern’s effectiveness depends on how and where it’s used. It would be the most useful when:

An application uses a large number of objects;
The objects drain all available RAM on a target device;
The objects contain duplicate states which can be extracted and shared between multiple objects;
Many groups of objects could be replaced by a few shared objects once the extrinsic state is removed;
The application doesn’t depend on object identity. Since flyweight objects are shared, conceptually distinct objects could be considered as the same object.

Implementation

Sadly, the implementation would not resolve any real-world problem this time, but we will implement a simple representation screen and later investigate how the usage of the Flyweight design pattern reduces memory consumption.

Let’s say, we want to draw our custom background using two different geometric shapes — circles and squares. Also, in the background, we want to put a total of 1000 shapes at random positions. This will be implemented in two different ways:

A new shape object would be created for each shape in the background;
A flyweight factory would be used which creates a single object per shape.

Later, we will use a profiler tool for Dart Apps — Observatory — to investigate how much memory is used for each of these implementations. Let’s check the class diagram first and then implement the pattern.

Class diagram

The class diagram below shows the implementation of the Flyweight design pattern:

The ShapeType is an enumerator class defining possible shape types — Circle and Square.

The IPositionedShape is an abstract class that is used as an interface for the specific shape classes:

render() — renders the shape — returns the positioned shape widget. Also, the extrinsic state (x and y coordinates) are passed to this method to render the shape in the exact position.

Circle and Square are concrete positioned shape classes that implement the abstract class IPositionedShape. Both of these shapes have their own intrinsic state: circle defines color and diameter properties while square contains color, width properties and a getter height which returns the same value as width.

The ShapeFactory is a simple factory class that creates and returns a specific shape object via the createShape() method by providing the ShapeType.

The ShapeFlyweightFactory is a flyweight factory that contains a map of flyweight objects — shapesMap. When the concrete flyweight is requested via the getShape() method, the flyweight factory checks whether it exists in the map and returns it from there. Otherwise, a new instance of the shape is created using the ShapeFactory and persisted in the map object for further usage.

The FlyweightExample initialises and contains the ShapeFlyweightFactory object. Also, it contains a list of positioned shape — shapesList — which is built using the ShapeFlyweightFactory and flyweight positioned shape objects.

ShapeType

A special kind of class — enumeration — to define different shape types.

IPositionedShape

An interface that defines the render() method to be implemented by concrete shape classes. Dart language does not support the interface as a class type, so we define an interface by creating an abstract class and providing a method header (name, return type, parameters) without the default implementation.

Concrete shapes

Circle — a specific implementation of the IPositionedShape interface representing the shape of a circle.

Square — a specific implementation of the IPositionedShape interface representing the shape of a square.

ShapeFactory

A simple factory class that defines the createShape() method to create a concrete shape by providing its type.

ShapeFlyweightFactory

A flyweight factory class that keeps track of all the flyweight objects and creates them if needed.

Example

First of all, a markdown file is prepared and provided as a pattern’s description:

FlyweightExample initialises and contains the ShapeFlyweightFactory class object. Also, for demonstration purposes, the ShapeFactory object is initialised here, too. Based on the selected option, either the ShapeFactory or ShapeFlyweightFactory is used to populate a list of IPositionedShape objects which are rendered in the background of the example screen.

With the ShapeFlyweightFactory, the client — FlyweightExample widget — does not care about the flyweight objects’ creation or management. IPositionedShape objects are requested from the factory by passing the ShapeType, flyweight factory keeps all the instances of the needed shapes itself, only returns references to them. Hence, only a single instance of a shape object per type could be created and reused when needed.

From the example, we could see that either 2 or 1000 shape instances are created to build the screen background. However, to understand what is happening under the hood, we can check the memory consumption using Dart Observatory.

When we access the Markdown screen of the Flyweight design pattern, Circle and Square instances are not created since they are not visible on the screen:

Before rendering the Example screen (without using flyweight factory), a total of 1000 shape instances are created — in this case, 484 circles and 516 squares:

When we use the flyweight factory, only one instance per specific shape is needed which is initiated and then shared (reused) later:

One shape instance uses 16 bytes of memory, so when we initiate 1000 shapes, that is ~16kB of memory in total. However, when a flyweight factory is used, only 32 bytes are enough to store all different shape instances — 500 times less memory is needed! Now, if you increase the number of shapes to 1 million, without the flyweight factory you would need ~15.2MB of memory to store them, but with a flyweight factory, the same 32 bytes would be enough.

All of the code changes for the Flyweight design pattern and its example implementation could be found here.

Your Contribution

18 - Builder

Mangirdas Kazlauskas 🚀 — Mon, 17 May 2021 13:56:05 +0000

Previously in the series, I have 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.

What is the Builder design pattern?
Analysis
Implementation
Your Contribution

What is the Builder design pattern?

Builder is a creational design pattern, which intention in the GoF book is described like this:

Separate the construction of a complex object from its representation so that the same construction process can create different representations.

The intention could be split into two parts:

Separate the construction of a complex object from its representation…

You should have already noticed this in the majority of the design patterns overviewed in the series, maybe in a slightly different form, e.g. separate the abstraction from its representation. In this case, one of the main purposes of the Builder design pattern is to separate the creation process (logic) of a complex object from the object (data) itself. What is a complex object? Well, there is no specific point or any criteria of the object when you could say that it is complex. Usually, an object could be considered as complex when the object’s creation does not simply end with calling its constructor — additionally, you should set some extra specific parameters, call additional methods.

Ok, at this point we have a complex object, we can create it by using some additional parameters and/or methods — why we need any additional abstraction on top of that, why we should separate this creation process from the object at all?

… so that the same construction process can create different representations.

Ahh, that’s the point! To understand it better, let’s say we are building a house. To build a house (object), the construction steps (build logic) are pretty much the same — you need the foundation, floor, some walls, doors, windows, a roof, etc. Even though the construction process of the house is the same, each of these steps could be adjusted, hence the final result would look completely different. And that is the main idea of the Builder design pattern — abstract the object’s creation process so that constructions steps could be adjusted to provide a different representation (final result).

The Builder design pattern moves the object construction code out of its own class to separate objects called builders. Each of these builders follows the same interface and implements separate object’s construction steps. That is, if you want a different object’s representation, just create a different builder class and implement these construction steps correspondingly. Also, there is one additional layer in the Builder design pattern — Director. The Director is a simple class that is aware of the Builder interface and defines the order in which to execute the building steps. This class is not mandatory, though, but it hides the details of product construction from the client code.

I know, the structure of the Builder design pattern is quite complex, so let’s move to the analysis and implementation parts to understand it better!

Analysis

The general structure of the Builder design pattern looks like this:

Builder — defines an abstract interface that is common to all types of builders for creating parts of a Product;
Concrete Builder — provides a specific implementation of the construction steps. Also, it defines and keeps track of the Product it creates;
Director — constructs an object using the Builder interface, defines the order in which the construction steps are called;
Product — represents the complex object under construction, exposes interface/methods for assembling the parts into the final result;
Client — associates the specific Builder object with the Director. Later, a Product object is created by calling the Director class instance.

Applicability

The Builder design pattern should be used when you notice multiple constructors of the same class referencing each other. For instance, you have a constructor with multiple optional parameters. Some of these parameters have default values, so you create several shorter constructors with fewer parameters, but still refer to the main one. By using the Builder design pattern, you are building objects step by step only using those steps that are really needed — you do not need to cope with the problem of multiple constructors with optional parameters anymore.

As already mentioned, this pattern should be used when you want to create different representations of some product. That is, the pattern could be applied when the construction steps are similar, but they differ in the details. The builder interface defines those steps (some of them may even have the default implementation) while concrete builders implement these steps to construct a particular representation of the product.

Finally, the Builder design pattern is useful when the algorithm for creating a complex object should be independent of the parts that make up the objects and how they are assembled. In simple words, it is just a simple extraction of the object’s creation logic from its own class. Therefore, the construction algorithm could evolve separately from the actual product it provides, the modification of this process does require changing the object’s code.

Implementation

This time, the implementation part is very straightforward — we will use the Builder design pattern to implement the build process of McDonald’s burgers.

As you may know, McDonald’s menu contains multiple burgers (regular burger, cheeseburger, Big Mac just to name a few). All of these burgers use the very same products, just the ingredients list is different:

Regular burger — buns, beef patty, ketchup, mustard, grill seasoning, onions, pickle slices;
Cheeseburger — buns, beef patty, cheese, ketchup, mustard, grill seasoning, onions, pickle slices;
Big Mac — buns, cheese, beef patty, Big Mac sauce, grill seasoning, onions, pickle slices, shredded lettuce.

As you can see, by changing the build process of the burger (changing ingredients), we completely change the final result. Also, at any moment there could be a requirement to add a new burger to the menu. Finally, the user-friendly UI should be implemented where you can select a burger from the menu and see its price, ingredients and allergens list.

For this problem, the Builder design pattern is a great option since we can define different builder classes which build specific burgers. Also, if a new burger should be added to the menu at any point, we can simply introduce another builder class to cope with this change. Let’s check the class diagram first and then implement the pattern.

Class diagram

The class diagram below shows the implementation of the Builder design pattern:

The Ingredient is an abstract class that is used as a base class for all the ingredient classes. The class contains allergens and name properties as well as getAllergens() and getName() methods to return the values of these properties.

There are a lot of concrete ingredient classes: BigMacBun, RegularBun, BeefPatty, McChickenPatty, BigMacSauce, Ketchup, Mayonnaise, Mustard, Onions, PickleSlices, ShreddedLettuce, Cheese and GrillSeasoning. All of these classes represent a specific ingredient of a burger and contains a default constructor to set the allergens and name property values of the base class.

Burger is a simple class representing the product of a builder. It contains the ingredients list and price property to store the corresponding values. Also, the class contains several methods:

addIngredient() — adds an ingredient to the burger;
getFormattedIngredients() — returns a formatted ingredients’ list of a burger (separated by commas);
getFormattedAllergens() — returns a formatted allergens’ list of a burger (separated by commas);
getFormattedPrice() — returns a formatted price of a burger;
setPrice() — sets the price for the burger.

BurgerBuilderBase is an abstract class that is used as a base class for all the burger builder classes. It contains burger and price properties to store the final product — burger — and its price correspondingly. Additionally, the class stores some methods with default implementation:

createBurger() — initialises a Burger class object;
getBurger() — returns the built burger result;
setBurgerPrice() — sets the price for the burger object.

BurgerBuilderBase also contain several abstract methods which must be implemented in the specific implementation classes of the burger builder: addBuns(), addCheese(), addPatties(), addSauces(), addSeasoning() and addVegetables().

BigMacBuilder, CheeseburgerBuilder, HamburgerBuilder and McChickenBuilder are concrete builder classes that extend the abstract class BurgerBuilderBase and implement its abstract methods.

BurgerMaker is a director class that manages the burger’s build process. It contains a specific builder implementation as a burgerBuilder property, prepareBurger() method to build the burger and a getBurger() method to return it. Also, the builder’s implementation could be changed using the changeBurgerBuilder() method.

BuilderExample initialises and contains the BurgerMaker class. Also, it references all the specific burger builders which could be changed at run-time using the UI dropdown selection.

Ingredient

An abstract class that stores the allergens, name fields and is extended by all of the ingredient classes.

Concrete ingredients

All of these classes represent a specific ingredient by extending the Ingredient class and specifying an allergens’ list as well as the name value.

Big Mac Bun

Regular Bun

Cheese

Grill Seasoning

Beef Patty

McChicken Patty

Big Mac Sauce

Ketchup

Mayonnaise

Mustard

Onions

Pickle Slices

Shredded Lettuce

Burger

A simple class to store information about the burger: its price and a list of ingredients it contains. Also, class methods, such as getFormattedIngredients(), getFormattedAllergens() and getFormattedPrice(), returns these values in human-readable format.

BurgerBuilderBase

An abstract class that stores burger and price properties defines some default methods to create/return the burger object and set its price. Also, the class defines several abstract methods which must be implemented by the derived burger builder classes.

Concrete builders

BigMacBuilder — builds a Big Mac using the following ingredients: BigMacBun, Cheese, BeefPatty, BigMacSauce, GrillSeasoning, Onions, PickleSlices and ShreddedLettuce.

CheeseburgerBuilder — builds a cheeseburger using the following ingredients: RegularBun, Cheese, BeefPatty, Ketchup, Mustard, GrillSeasoning, Onions and PickleSlices.

HamburgerBuilder — builds a cheeseburger using the following ingredients: RegularBun, BeefPatty, Ketchup, Mustard, GrillSeasoning, Onions and PickleSlices. AddCheese() method is not relevant for this builder, hence the implementation is not provided (skipped).

McChickenBuilder — builds a cheeseburger using the following ingredients: RegularBun, McChickenPatty, Mayonnaise and ShreddedLettuce. AddCheese() and addSeasoning() methods are not relevant for this builder, hence the implementation is not provided (skipped).

BurgerMaker

A director class that manages the burger’s build process and returns the build result. A specific implementation of the builder is injected into the class via the constructor.

Example

First of all, a markdown file is prepared and provided as a pattern’s description:

BuilderExample initialises and contains the BurgerMaker class object. Also, it contains a list of BurgerMenuItem objects/selection items which is used to select the specific builder using UI.

The director class BurgerMaker does not care about the specific implementation of the builder — the specific implementation could be changed at run-time, hence providing a different result. Also, this kind of implementation allows easily adding a new builder (as long as it extends the BurgerBuilderBase class) to provide another different product’s representation without breaking the existing code.

As you can see in the example when a specific builder is selected from the dropdown list, a new product (burger) is created and its information is provided in the UI — price, ingredients and allergens.

All of the code changes for the Builder design pattern and its example implementation could be found here.

Your Contribution

17 - Bridge

Mangirdas Kazlauskas 🚀 — Mon, 10 May 2021 12:37:29 +0000

In the last article, I have 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.

What is the Bridge design pattern?
Analysis
Implementation
Your Contribution

What is the Bridge design pattern?

Bridge, also known as Handle/Body, belongs to the category of structural design patterns. The intention of this design pattern is described in the GoF book:

Decouple an abstraction from its implementation so that the two can vary independently.

The usual way for an abstraction to have one of several possible implementations is to use inheritance — an abstraction defines the interface while concrete subclasses implement it in different ways. However, this approach is not very flexible since it binds the implementation to abstraction at compile-time and makes it impossible to change the implementation at run-time. What if we want the implementation to be selected and exchanged at run-time?

The Bridge design pattern separates an abstraction from its implementation so that the two can vary independently from each other. In this case, the abstraction uses another abstraction as its implementation instead of using the implementation directly. This relationship between an abstraction and its implementation (well, another abstraction, to be more specific) is called a bridge — it bridges the abstraction and its implementation, letting them vary independently.

If the Abstraction and Implementation terms sound too academic to you, imagine this: abstraction (or interface) is just a high-level layer for some particular entity. This layer is just an interface that is not supposed to do any real work on its own — it should delegate the work to the implementation layer. A good example of this is a GUI (graphical user interface) and OS (operating system). GUI is just a top-level layer for the user to communicate with the operating system, but it does not do any real work by itself — it just passes user commands (events) to the platform. And what is important about this, both GUI and OS could be extended separately from each other, e.g. a desktop application could have different views/panels/dashboards and at the same time support several APIs (could be run on Windows, Linux and macOS) — these two parts could vary independently. Sounds like a Bridge design pattern, right?

Analysis

The general structure of the Bridge design pattern looks like this:

Abstraction — defines an interface for the abstraction and maintains a reference to an object of type Implementation;
Refined abstraction — implements the Abstraction interface and provides different variants of control logic;
Implementation — defines an interface for the implementation classes. An Abstraction can only communicate with an Implementation object via methods that are declared there;
Concrete implementations — implement the Implementation interface and contain platform-specific code.

Applicability

The Bridge design pattern should be used when you want to divide a monolithic class with several functionality variants. In this case, the pattern allows splitting the class into several class hierarchies which could be changed independently — it simplifies code maintenance, smaller classes minimizes the risk of breaking existing code. A good example of this approach is when you want to use several different approaches in the persistence layer e.g. both database and file system persistence.

The bridge design pattern should also be used when both the abstractions and their implementations should be extensible by subclassing — the pattern allows combining different abstractions and implementation and extending them independently.

Finally, the bridge design pattern is a lifesaver when you need to be able to switch implementations at run-time. The pattern lets you replace the implementation object inside the abstraction — you can inject it via the constructor or just assign it as a new value to a field/property.

Implementation

We will implement the persistence layer for our example using the Bridge design pattern for the implementation part.

Let’s say your application uses the external SQL database (not the local SQLite option in your device, but the cloud one). Everything is fine until the wild connection problems appear. In this case, there are two options: you are not allowing users to use the application and provide a funny connection lost screen or you can store the data in some kind of local storage and synchronise the data later when the connection is up again. Obviously, the second approach is more user friendly, but how to implement it?

In the persistence layer, there are multiple repositories for each entity type. The repositories share a common interface — that is our abstraction. If you want to change the storage type (to use the local or cloud one) at run-time, these repositories could not reference the specific implementation of the storage, they should use some kind of abstraction shared between different types of storages. Well, we can build another abstraction (interface) on top of that which is then implemented by the specific storages. Now we connect our repositories’ abstraction with the storages’ interface — voilà, that is how the Bridge design pattern is introduced into our application! Let’s check the class diagram first and then investigate some implementation details.

Class diagram

The class diagram below shows the implementation of the Bridge design pattern:

The EntityBase is an abstract class that is used as a base class for all the entity classes. The class contains an id property and a named constructor EntityBase.fromJson to map the JSON object to the class field.

Customer and Order are concrete entities that extend the abstract class EntityBase. Customer class contains name and email properties, Customer.fromJson named constructor to map the JSON object to class fields and a toJson() method to map class fields to the corresponding JSON map object. Order class contain dishes (a list of dishes of that order) and total fields, a named constructor Order.fromJson and a toJson() method respectively.

IRepository is an abstract class that is used as an interface for the repositories:

getAll() — returns all records from the repository;
save() — saves an entity of type EntityBase in the repository.

CustomersRepository and OrdersRepository are concrete repository classes that extend the abstract class IRepository and implement its abstract methods. Also, these classes contain a storage property of type IStorage which is injected into the repository via the constructor.

IStorage is an abstract class that is used as an interface for the storages:

getTitle() — returns the title of the storage. The method is used in UI;
fetchAll() — returns all the records of type T from the storage;
store() — stores a record of type T in the storage.

FileStorage and SqlStorage are concrete storage classes that extend the abstract class IStorage and implement its abstract methods. Additionally, FileStorage class uses the JsonHelper class and its static methods to serialise/deserialise JSON objects.

BridgeExample initialises and contains both — customer and order — repositories which are used to retrieve the corresponding data. Additionally, the storage type of these repositories could be changed between the FileStorage and SqlStorage separately and at the run-time.

EntityBase

An abstract class that stores the id field and is extended by all of the entity classes.

Customer

A simple class to store information about the customer: its name and email. Also, the constructor generates random values when initialising the Customer object.

Order

A simple class to store information about the order: a list of dishes it contains and the total price of the order. Also, the constructor generates random values when initialising the Order object.

JsonHelper

A helper classes used by the FileStorage to serialise objects of type EntityBase to JSON map objects and deserialise them from the JSON string.

IRepository

An interface that defines methods to be implemented by the derived repository classes. Dart language does not support the interface as a class type, so we define an interface by creating an abstract class and providing a method header (name, return type, parameters) without the default implementation.

Concrete repositories

CustomersRepository — a specific implementation of the IRepository interface to store customers’ data.

OrdersRepository — a specific implementation of the IRepository interface to store orders’ data.

IStorage

An interface that defines methods to be implemented by the derived storage classes.

Concrete storages

FileStorage — a specific implementation of the IStorage interface to store an object in the storage as a file — this behaviour is mocked by storing an object as a JSON string.

SqlStorage — a specific implementation of the IStorage interface to store an object in the storage as an entity — this behaviour is mocked by using the Map data structure and appending entities of the same type to the list.

Example

First of all, a markdown file is prepared and provided as a pattern’s description:

BridgeExample contains a list of storages — instances of SqlStorage and FileStorage classes. Also, it initialises Customer and Order repositories. In the repositories the concrete type of storage could be interchanged by triggering the onSelectedCustomerStorageIndexChanged() for the CustomersRepository and onSelectedOrderStorageIndexChanged() for the OrdersRepository respectively.

The concrete repository does not care about the specific type of storage it uses as long as the storage implements the IStorage interface and all of its abstract methods. As a result, the abstraction (repository) is separated from the implementor (storage) — the concrete implementation of the storage could be changed for the repository at run-time, the repository does not depend on its implementation details.

As you can see in the example, the storage type could be changed for each repository separately and at run-time — it would not be possible by using the simple class inheritance approach.

All of the code changes for the Bridge design pattern and its example implementation could be found here.

Your Contribution

16 - Decorator

Mangirdas Kazlauskas 🚀 — Mon, 03 May 2021 07:52:38 +0000

Previously in the series, I have analysed a relatively simple, but very practical design pattern — Proxy. This time I would like to represent a design pattern, which, unlike the Strategy design pattern, extends the functionality of an object instead of exchanging it. It is a structural design pattern called Decorator.

What is the Decorator design pattern?
Analysis
Implementation
Your Contribution

What is the Decorator design pattern?

Decorator, also known as Wrapper, is a structural design pattern, which intention in the GoF book is described like this:

Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

The Decorator design pattern provides a way of changing the skin of an object without changing its guts — it extends an object’s functionality by wrapping it in an object of a Decorator class, leaving the original object intact without modification. Therefore, the pattern helps support one of the SOLID principles — the Open/Closed Principle (classes should be closed for modification, but open for extension).

The decorations (decorator classes) are independent of each other, hence they can be composed and chained together to add multiple behaviours (inception flashbacks, huh?). Also, another advantage is that this behaviour could be added at run-time, which leads to very flexible reuse of code, unlike using class inheritance. In addition to this, changing the order of decorators allows adding any combinations of responsibilities. However…

With great power comes great responsibility

The usage of the Decorator design pattern can also increase the complexity of code. To implement a specific component and make it modifiable at the run-time, not only you need to implement the Component, but also an indefinite amount of Decorator classes should be added to wrap it. A larger number of classes can sometimes be overwhelming, also debugging and testing the component wrapped by several additional classes does not make the development easier, too.

Let’s move to the analysis and implementation parts to understand and learn the details about this pattern and how to implement it!

Analysis

The general structure of the Decorator design pattern looks like this:

Component — defines the interface for objects that can have responsibilities added to them dynamically;
Concrete Component — defines an object to which additional responsibilities can be added. It contains the basic behaviour which can be altered by decorators;
Base Decorator — has a field referencing a wrapped object which type should be declared as the component interface so it can contain both concrete components and decorators;
Concrete Decorators — adds responsibilities (extra behaviour) to the components dynamically;
Client — initialises the concrete component and wraps it in multiple layers of decorators extending its default behaviour dynamically.

Applicability

The Decorator design pattern should be used when you need to add extra responsibilities to objects dynamically (at run-time) without affecting other objects. Since all the decorator objects implement the same interface, they can be used in various combinations and interchanged with each other.

Also, this design pattern is useful when extension by subclassing is impractical or even not possible. For instance, sometimes a large number of independent extensions are possible and would produce a huge number of subclasses to support every combination — for those cases, the Decorator design pattern is a better option.

Finally, the Decorator design pattern could be simply used to refactor the code base and split components with hard-wired extensions (compile-time implementation dependencies) into separate classes. As a result, code becomes more readable/maintainable (there would be less code in smaller classes) and at the same time more flexible.

Implementation

In the Flutter community, it is quite popular to create food delivery/restaurant type of applications. With the implementation of the Decorator design pattern, we will jump into this hype train and will build a prototype for the pizza delivery application, to be more specific, for the pizza selection from the menu.

Let’s say we have a small restaurant which makes 3 kinds of pizza:

Margherita — Sauce, Mozzarella, Basil, Oregano, Pecorino, Olive Oil;
Pepperoni — Sauce, Mozzarella, Pepperoni, Oregano;
“Make-Your-Own” — any combination of pizza toppings from the list of Basil, Mozzarella, Olive Oil, Oregano, Pecorino, Pepperoni, and Sauce.

All the pizzas are of the same size, pizza toppings have different prices.

It is quite clear for the pizza Margherita or Pepperoni — the recipe is clear, you just need to add the necessary toppings and calculate the final price, easy peasy. However, for the custom pizza, it would be very impractical to prepare the pre-defined recipes for all the possible combinations — that’s just not how it works usually from the business point of view.

For this problem, the Decorator design pattern is a great option since we can make the pizza toppings as separate decorator classes, use them to wrap the pizza base (the base component) and calculate the final price of the pizza based on the selected toppings. Let’s check the class diagram first and then implement the pattern.

Class diagram

The class diagram below shows the implementation of the Decorator design pattern:

Pizza defines a common interface for wrappers (decorators) and wrapped objects:

getDescription() — returns the description of the pizza;
getPrice() — returns the price of the pizza.

PizzaBase represents the component object which extends the Pizza class and implements its abstract methods.

PizzaDecorator references the Pizza object and forwards requests to it via the getDescription() and getPrice() methods.

Basil, Mozzarella, OliveOil, Oregano, Pecorino, Pepperoni and Sauce are concrete decorators extending the PizzaDecorator class and overriding its default behaviour by adding some extra functionality/calculations of their own.

PizzaToppingData class stores information about the pizza topping’s selection chip used in the UI — its label and whether it is selected or not.

PizzaMenu class provides a getPizzaToppingsDataMap() method to retrieve the pizza topping’s selection chip data. Also, getPizza() method is defined to return the specific Pizza object based on the selected index in the UI or the selected pizza toppings.

DecoratorExample initialises and contains the PizzaMenu class object to retrieve the selected Pizza object based on the user’s selection in the UI.

Pizza

An abstract class of the Pizza component that defines a common interface for concrete component and decorator objects.

PizzaBase

A concrete component that extends the Pizza class and implements its methods. An object of this class (its behaviour) gets decorated by the specific decorator classes.

PizzaDecorator

An abstract decorator class that maintains a reference to a component class and forwards requests to it.

Concrete pizza decorators

Basil, Mozzarella, OliveOil, Oregano, Pecorino, Pepperoni and Sauce are concrete decorator classes of the Pizza component. Each of these classes wraps the pizza object and adds additional value for the final price in the getPrice() method, also extends the final pizza’s description in the getDescription() method.

Basil:

Mozzarella:

Olive Oil:

Oregano:

Pecorino:

Pepperoni:

Sauce:

PizzaToppingData

A simple class that contains data used by the pizza topping’s selection chip in the UI. The data consists of the label property and the current selection state (whether the chip is currently selected or not) which could be changed by using the setSelected() method.

PizzaMenu

A simple class that provides a map of PizzaToppingData objects via the getPizzaToppingsDataMap() method for the pizza toppings selection in UI. Also, the class defines a getPizza() method which returns a Pizza object that is built by using the pre-defined concrete decorator classes based on the pizza recipe — Margherita, Pepperoni or custom (based on the selected pizza toppings).

This class (to be more specific, getMargherita(), getPepperoni() and getCustom() methods) represents the main idea of the decorator design pattern — a base component class is instantiated and then wrapped by the concrete decorator classes, hence extending the base class and its behaviour. As a result, it is possible to use wrapper classes and add or remove responsibilities from an object at runtime, for instance, as it is used in the getCustom() method where the appropriate decorator classes are used based on the selected pizza toppings data in the UI.

Example

First of all, a markdown file is prepared and provided as a pattern’s description:

DecoratorExample contains the PizzaMenu object which is used to get the specific Pizza object based on the user’s selection. Also, all the logic related to the decorator’s design pattern and its implementation is extracted to the PizzaMenu class, the DecoratorExample widget only uses it to retrieve the necessary data to be represented in the UI.

The final result looks like this:

As you can see in the example when selecting any of the pre-defined recipes, the final price of the pizza is recalculated as well as the description of its toppings is provided. Also, for the custom pizza, the price is recalculated every time a topping is selected or deselected, the pizza’s description is updated, too.

All of the code changes for the Decorator design pattern and its example implementation could be found here.

Your Contribution

15 - Proxy

Mangirdas Kazlauskas 🚀 — Mon, 26 Apr 2021 11:01:04 +0000

In the last article, I have analysed a relatively simple design pattern comparing 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 Proxy.

What is the Proxy design pattern?
Analysis
Implementation
Your Contribution

What is the Proxy design pattern?

Proxy, also known as Surrogate, belongs to the category of structural design patterns. The intention of this design pattern is described in the GoF book:

Provide a surrogate or placeholder for another object to control access to it.

The key idea in this pattern is to work through a separate proxy object that performs additional functionality when accessing an (already existing) object. For instance, the user’s rights should be validated before accessing the object or the object’s creation is very expensive so it makes sense to defer its creation until the object is actually needed. Also, if you need to execute something either before or after the primary logic of the class, the proxy lets you do this without changing that class. Since the proxy implements the same interface as the original class, it can be passed to any client that expects a real service object.

To understand the Proxy design pattern better, let’s dive in by analysing its structure, types and implementation in more detail!

Analysis

The general structure of the Proxy design pattern looks like this:

ServiceInterface — defines the common interface for Service and Proxy that the proxy service could be used instead of the real one;
Service — defines the real object which contains some useful business logic. This is the service that the proxy represents;
Proxy — implements the same interface as the real service. Also, has a reference field that points to a service object which allows controlling access to it. The Proxy class may be responsible for creating and deleting the real service’s object;
Client — should work with both services and proxies via the same interface. This way you can pass a proxy into any code that expects a service object.

Applicability

There are dozens of ways to utilize the Proxy pattern:

Lazy initialization (virtual proxy) — instead of creating the object when the app launches, you can delay the object’s initialization to a time when it’s really needed;
Access control (protection proxy) — the proxy can pass the request to the service object only if the client’s credentials match some criteria;
Local execution of a remote service (remote proxy) — the proxy passes the client request over the network, handling all of the nasty details of working with the network;
Logging requests (logging proxy) — the proxy can log each request before passing it to the service;
Caching request results (caching proxy) — the proxy can implement caching for recurring requests that always yield the same results. The proxy may use the parameters of requests as the cache keys.

Implementation

For the following example of the Proxy design pattern, we will implement the caching proxy.

In my opinion, in any application which loads resources from an external service, it is quite a common problem to improve the performance and reduce load times of the data. It is possible to optimise and at least partially resolve it by implementing the caching layer.

Let’s say we have a list of customers with some basic information — customer’s id and name. Any additional customer data should be loaded from an external web service. When providing the general list of customers, additional information is not loaded nor used. However, it could be accessed by selecting a specific customer and loading its data from the customer details service. To reduce the number of requests sent to the external service, it makes sense to introduce a caching layer to the application and provide the already loaded information from the cache for future requests.

To achieve this, the Proxy design pattern is a great choice! Let’s check the class diagram first and then implement a proxy for the customer details service.

Class diagram

The class diagram below shows the implementation of the Proxy design pattern:

Customer class is used to store information about the customer. One of its properties is the CustomerDetails which stores additional data about the customer e.g. its email, hobby and position.

ICustomerDetailsService is an abstract class that is used as an interface for the customer details service:

getCustomerDetails() — an abstract method that returns details for the specific customer.

CustomerDetailsService is the “real” customer details service that implements the abstract class ICustomerDetailsService and its methods.

CustomerDetailsServiceProxy is a proxy service that contains the cache (dictionary object) and sends the request to the real CustomerDetailsService only if the customer details object is not available in the cache.

ProxyExample initialises and contains the proxy object of the real customer details service. When a user selects the option to see more details about the customer, the dialog window appears and loads details about the customer. If the details object is already stored inside the cache, the proxy service returns that object instantly. Otherwise, a request is sent to the real customer details service and the details object is returned from there.

Customer

A simple class to store information about the customer: its id, name and details. Also, the constructor generates random id and name values when initialising the Customer object.

CustomerDetails

A simple class to store information about customer details: id to map the details information with the corresponding customer, e-mail address, hobby and the current position (job title).

ICustomerDetailsService

An interface that defines the getCustomerDetails() method to be implemented by the customer details service and its proxy. Dart language does not support the interface as a class type, so we define an interface by creating an abstract class and providing a method header (name, return type, parameters) without the default implementation.

CustomerDetailsService

A specific implementation of the ICustomerDetailsService interface — the real customer details service. The getCustomerDetails() method mocks the real behaviour of the service and generates random values of customer details.

CustomerDetailsServiceProxy

A specific implementation of the ICustomerDetailsService interface — a proxy for the real customer details service. Before making a call to the customer details service, the proxy service checks whether the customer details are already fetched and saved in the cache. If yes, the customer details object is returned from the cache, otherwise, a request is sent to the real customer service and its value is saved to the cache and returned.

Example

First of all, a markdown file is prepared and provided as a pattern’s description:

ProxyExample contains the proxy object of the real customer details service. When the user wants to see customer details, the showDialog() method is triggered (via the showCustomerDetails() method) which opens the dialog window of type CustomerDetailsDialog and passes the proxy object via its constructor as well as the selected customer’s information — the Customer object.

The CustomerDetailsDialog class uses the passed proxy service on its state’s initialisation, hence loading details of the selected customer.

The CustomerDetailsDialog class does not care about the specific type of customer details service as long as it implements the ICustomerDetailsService interface. As a result, an additional caching layer could be used by sending the request through the proxy service, hence improving the general performance of the application, possibly saving some additional network data and reducing the number of requests sent to the real customer details service as well. Also, if you want to call the real customer details service directly, you can just simply pass it via the CustomerDetailsDialog constructor — no additional changes are needed in the UI code since both the real service and its proxy implements the same interface.

As you can see in the example, when trying to load the specific customer’s details for the first time, it takes some time for the information to load from the service. However, when the same information is accessed once again, it is provided from the cache stored in the proxy service, hence the request is not sent to the real customer details service — the customer details information is provided instantly.

All of the code changes for the Proxy design pattern and its example implementation could be found here.

Your Contribution

14 - Prototype

Mangirdas Kazlauskas 🚀 — Mon, 19 Apr 2021 07:38:47 +0000

Previously in the series, I have analyzed one of the behavioural design patterns — Memento. This time I would like to represent a relatively simple design pattern comparing to the other patterns in the series that belongs to the category of creational design patterns — the Prototype.

What is the Prototype design pattern?
Analysis
Implementation
Your Contribution

What is the Prototype design pattern?

The Prototype is a creational design pattern, which intention in the GoF book is described like this:

Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.

That is, instead of creating a new object, some prototype is used which allows creating new objects by copying from this prototype. This could be useful when you want to copy an object which has a complicated state, which means that just initialising a new object will not be enough, you also need to reach that particular state of the object to consider it as a valid copy. In simple words, when your code only wants a copy of a specific object with the same state and you do not care about the details on how this state was reached — well, your code should just provide a way to copy (clone) it.

In general, an inflexible way is to create an object directly within the class that requires (uses) the object. The Prototype design pattern enables the run-time flexibility since a class can be configured with different Prototype objects, which are copied to create new objects, and even more, Prototype objects can be added and removed dynamically at run-time.

Let’s move to the analysis and implementation parts to understand and learn the details about this pattern and how to implement it!

Analysis

The general structure of the Prototype design pattern looks like this:

Prototype — declares an interface for cloning itself. Usually, it is a single clone method, but there could be other methods declared/defined if needed;
ConcretePrototype — implements an operation for cloning itself. In addition to copying the original object’s data to the clone, this method may also handle some edge cases of the cloning process related to cloning linked objects, untangling recursive dependencies, etc.;
SubclassPrototype — has the same purpose as the ConcretePrototype, but could also extend the base class by defining additional properties, behaviour, etc.;
Client — creates a new object by asking a prototype to clone itself.

Applicability

The Prototype design pattern should be used when your code should not depend on the concrete classes of objects that you need to copy. The Prototype pattern provides the client code with a general interface for working with all objects that support cloning. This interface makes the client code independent from the concrete classes of objects that it clones.

Also, the pattern could be used when you want to reduce the number of subclasses that only differ in the way they initialize their respective objects. Instead of instantiating a subclass that matches some configuration, the client can simply look for an appropriate prototype and clone it.

Finally, the pattern is quite useful when you have a set of pre-built objects that are ready to be copied. These objects could be stored inside some kind of prototype registry from which you can access the frequently-used prototypes. In this way, you can instantiate a dynamically loaded class and use it inside your code.

Implementation

This time, the implementation part of the design pattern is very simple and straightforward (but that could be also a good sign, right?). Let’s say there are multiple shapes in your application that should be copied at run-time and provided to the UI. Of course, it is possible to instantiate a specific shape by checking all the properties and using them to just simply create another object. However, different shapes contain different properties, they are of a different type, hence the logic just to copy a specific shape could lead to a cumbersome mess in the application code base which you probably want to avoid.

Wouldn’t it be nice to have a unified way to copy any shape in your application without even considering any details about it in your client code? Well, we have just analysed the Prototype design pattern, maybe give it a try?

Class diagram

The class diagram below shows the implementation of the Prototype design pattern:

Shape is an abstract class that is used as a base class for all the specific shapes. The class contains a color property and defines several abstract methods:

clone() — an abstract method to clone (copy) the specific shape;
randomiseProperties() — an abstract method to randomise property values of the shape;
render() — an abstract method to render the shape. The method is used in UI.

Circle and Rectangle are concrete shape classes that extend the abstract class Shape and implement its abstract methods.

PrototypeExample initializes and contains several Shape objects. These objects are rendered in the UI using the render() method. Also, specific shape objects could be copied using clone() and their properties could be randomised using randomiseProperties() methods respectively.

Shape

An abstract class stores the shape’s colour and defines several abstract methods. Also, this class contains several constructors:

Shape() — a basic constructor to create a shape object with the provided colour value;
Shape.clone() — a named constructor to create a shape object as a copy of the provided Shape value.

Shapes

Circle — a specific class that defines the shape of a circle. The class defines a radius property, extends the Shape class and implements its abstract methods clone(), randomiseProperties() and render().

Rectangle — a specific class that defines the shape of a rectangle. The class defines height and width properties, extends the Shape class and implements its abstract methods clone(), randomiseProperties() and render().

Example

First of all, a markdown file is prepared and provided as a pattern’s description:

PrototypeExample contains a couple of Shape objects — Circle and Rectangle. By pressing the Randomise properties button, the values of the shape’s properties are randomised (the randomiseProperties() method is called on the shape). Also, if the Clone button is pressed, the clone() method is called on the shape and a copy of that particular shape is crated with the same values of all the properties.

The PrototypeExample does not care about the specific type of shape object as long as it extends the Shape abstract class and implements all of its abstract methods. As a result, the clone() method could be called on any shape, all of its properties are copied even though these are different on different shapes e.g. the circle has only the radius property which is specific for that particular shape, while the rectangle has two different properties — height and width.

As you can see in the example, it does not matter of which type the specific shape is. As long as it extends the prototype base class defining the clone() method, the shape object could be copied at any time and used across your code — whether it is your business logic or UI, it is irrelevant.

All of the code changes for the Prototype design pattern and its example implementation could be found here.

Your Contribution

13 - Memento

Mangirdas Kazlauskas 🚀 — Tue, 13 Apr 2021 15:04:31 +0000

In the last article, I have 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.

What is the Memento design pattern?
Analysis
Implementation
Your Contribution

What is the Memento design pattern?

Memento, also known as Token, belongs to the category of behavioural design patterns. The intention of this design pattern is described in the GoF book:

Without violating encapsulation, capture and externalize an object’s internal state so that the object can be restored to this state later.

The key idea in this pattern is to make an object (originator) itself responsible for saving and restoring its internal state. The internal state (a snapshot of it) is saved in another object — memento. The undo mechanism will request a memento from the originator when it needs to restore the originator’s internal state. Clients (caretaker) that are responsible for saving and restoring an originator’s internal state stores a list of memento objects so that a memento can be passed back to the originator to restore to a previous state. However, the caretaker itself isn’t permitted to access or modify a memento — only the originator object which created the specific memento is allowed to do that.

To understand the Memento design pattern better, let’s dive in by analysing its structure and implementation in more detail!

Analysis

The general structure of the Memento design pattern looks like this:

Memento — an interface which restricts access to the ConcreteMemento’s fields, only declares methods related to the memento’s metadata and which is used by the Caretaker to work with ConcreteMemento object;
ConcreteMemento — stores an Originator’s internal state. Also, protects against access by objects other than the Originator which has created the ConcreteMemento.
Caretaker — is responsible for the Memento’s safekeeping and never operates or examines the contents of a Memento.
Originator — creates a ConcreteMemento containing a snapshot of its current internal state. Also, provides the restore() method to restore the internal state using the ConcreteMemento.

Applicability

The Memento design pattern should be used when you want to produce snapshots of the object’s state to be able to restore a previous state of the object. The Memento pattern lets you make full copies of an object’s state, including private fields, and store them separately from the object.

Also, the pattern could be used for safety reasons — when direct access to the object’s fields/getters/setters violates its encapsulation. The Memento makes the object itself responsible for creating a snapshot of its state. No other object can read the snapshot, making the original object’s state data safe and secure.

Implementation

To implement the Memento design pattern and show its advantages, we will work further on the Command design pattern’s example. So if you have missed the previous article, I strongly recommend checking the implementation part of it now.

The main idea of the example remains the same — we will create a very simple, fake graphics editor. To simplify the Command design pattern’s part, only one command is created and available in the example’s UI — RandomisePropertiesCommand. This command randomises all the properties of the Shape object — height, width and colour — which acts as a state of our example.

Obviously, what is different from the previous implementation — the Memento design pattern is added. When implementing the Command design pattern’s example, we stored its state (Shape object) in the example component itself. This time, the state is stored inside the Originator object and could be manipulated only by it. The RandomisePropertiesCommand acts as a caretaker object and stores the previous snapshot of the originator’s state in the backup property. The backup property is nothing else than the Memento object which is created by the originator before executing the command.

As a result of using the Memento design pattern, the example’s state is encapsulated and moved outside from the example component. Also, the previous state could be restored from its Memento snapshot on undo() operation of the command. In this case, the Memento design pattern extends the Command design pattern and collaborates with it really well.

Before implementing the Memento design pattern and integrating it inside our example, let’s check the class diagram first and investigate its components.

Class diagram

The class diagram below shows the implementation of the Memento design pattern:

ICommand is an abstract class that is used as an interface for the specific command:

execute() — an abstract method that executes the command;
undo() — an abstract method that undoes the command and returns the state to the previous snapshot of it.

RandomisePropertiesCommand is a concrete command which implements the abstract class ICommand and its methods.

CommandHistory is a simple class that stores a list of already executed commands (commandList) and provides methods to add a new command to the command history list (add()) and undo the last command from that list (undo()).

IMemento is an abstract class that is used as an interface for the specific memento class:

getState() — an abstract method that returns the snapshot of the internal originator’s state.

Memento is a class that acts as a snapshot of the originator’s internal state which is stored in the state property and returned via the getState() method.

Shape is a simple data class that is used as an internal originator’s state. It stores multiple properties defining the shape presented in UI: color, height and width.

Originator — a simple class that contains its internal state and stores the snapshot of it to the Memento object using the createMemento() method. Also, the originator’s state could be restored from the provided Memento object using the restore() method.

MementoExample initializes and contains CommandHistory, Originator objects. Also, this component contains a PlatformButton widget that has the command of RandomisePropertiesCommand assigned to it. When the button is pressed, the command is executed and added to the command history list stored in CommandHistory object.

Shape

A simple class to store information about the shape: its color, height and width. Also, this class contains several constructors:

Shape() — a basic constructor to create a shape object with provided values;
Shape.initial() — a named constructor to create a shape object with pre-defined initial values;
Shape.copy() — a named constructor to create a shape object as a copy of the provided Shape value.

ICommand

An interface that defines methods to be implemented by the specific command classes. Dart language does not support the interface as a class type, so we define an interface by creating an abstract class and providing a method header (name, return type, parameters) without the default implementation.

RandomisePropertiesCommand

A specific implementation of the command that sets all the properties of the Shape object stored in the Originator to random values. Also, the class implements the undo operation.

CommandHistory

A simple class that stores a list of already executed commands. Also, this class provides isEmpty getter method to return true if the command history list is empty. A new command could be added to the command history list via the add() method and the last command could be undone using the undo() method (if the command history list is not empty).

IMemento

An interface that defines the getState() method to be implemented by the specific Memento class.

Memento

An implementation of the IMemento interface which stores the snapshot of Originator’s internal state (Shape object). The state is accessible to the Originator via the getState() method.

Originator

A class that defines a createMemento() method to save the current internal state to a Memento object.

Example

First of all, a markdown file is prepared and provided as a pattern’s description:

MementoExample contains CommandHistory and Originator objects. Also, this widget contains a PlatformButton component which uses the RandomisePropertiesCommand to randomise property values of the shape. After the command’s execution, it is added to the command history list stored in the CommandHistory object. If the command history is not empty, the Undo button is enabled and the last command could be undone.

As you can see in this example, the client code (UI elements, command history, etc.) isn’t coupled to any specific command class because it works with it via the ICommand interface.

In addition to what the Command design pattern provides to this example, the Memento design pattern adds an additional layer to the example’s state. It is stored inside the Originator object, the command itself does not mutate the state directly but through the Originator. Also, the backup (state’s snapshot) stored inside the Command is a Memento object and not the state (Shape object) itself — in case of the state’s restore (undo is triggered on the command), the specific command calls the restore method on the Originator which restores its internal state to the value stored in the snapshot. Hence, it allows restoring multiple property values (a whole complex state object) in a single request, while the state itself is completely separated from the command’s code or UI logic.

As you can see in the example, when the command is executed, under the hood the snapshot of the originator’s internal state is stored which could be restored later by executing the undo operation on the command.

All of the code changes for the Memento design pattern and its example implementation could be found here.

Your Contribution

12 - Command

Mangirdas Kazlauskas 🚀 — Mon, 05 Apr 2021 16:42:35 +0000

Previously in the series, I have analysed and implemented one of the most popular and useful creational design patterns — Abstract Factory. This time, I would like to introduce an OOP design pattern that belongs to the category of behavioural design patterns — the Command.

What is the Command design pattern?
Analysis
Implementation
Your Contribution

What is the Command design pattern?

Command, also known as Action or Transaction, is one of the behavioural design patterns which intention is described in the GoF book:

Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

That is, by encapsulating the request as an object, the client is completely decoupled from any of the details of how that command is implemented or how it will get executed — the client doesn’t have to care about any dependencies.

There are multiple components of which the Command design pattern is consisted of. Usually, Command objects serve as links between various UI and business logic objects. In this case, the command object could be bound to the UI element at runtime by the Client and that particular UI component, called Sender, invokes the request. The Sender triggers the assigned Command instead of sending the request directly to the Receiver - a simple or complex object which contains the actual logic for the request to be fulfilled. A specific Command passes the call to the receiver which does the actual work. As a result, commands become a convenient middle layer that reduces coupling between the UI and business logic layers.

Let’s move to the analysis and implementation parts to understand the details about this pattern and learn how to implement it!

Analysis

The general structure of the Command design pattern looks like this:

Command — declares an interface for executing an operation;
Concrete Commands (Command1/Command2) — implement various kinds of requests by invoking the corresponding operation(s) on Receiver;
Invoker — the sender class which triggers the Command instead of sending the request directly to the Receiver;
Receiver — knows how to perform the operations associated with carrying out a request. Any class may serve as a Receiver;
Client — creates a Concrete Command object and sets its Receiver.

Applicability

The Command design pattern could be used when you want to parameterize objects by an action to perform. That is, the operation (command) is extracted to a separate class which object could be passed as a method argument, stored inside another object or the linked command could be switched at runtime.

Furthermore, the Command design pattern is useful when you want to queue operations, schedule their execution, or execute them remotely. Since the command itself is just a simple class, its object (as any other object) could be serialized, stored, e.g. in the database or a text file and later restored as the initial command and executed. This is useful when you want to schedule a specific task that should be executed at a particular time, or on a recurring schedule.

Also, one of the most popular use-case for the Command is to use it for creating reversible operations. To be able to revert operations, you need to implement the history of performed operations. The command history is a stack that contains all executed command objects along with related backups of the application’s state.

Finally, the Command design pattern helps you write cleaner and reusable code. By using this pattern, you propagate the Single Responsibility Principle (the operation logic is decoupled from the component which performs that particular operation) and the Open/Closed Principle (introducing new commands to the application does not require changing the existing code).

Implementation

To show the Command design pattern in action, we will implement a fake graphics editor. The editor itself is super-ultra-mega-duper simplified (well, Photoshop should have started from something, right?) and provides the following functionality:

There is only one shape visible on the screen which cannot be removed, but its parameters (colour, height and width) could be adjusted using buttons;
Change the shape’s colour to a random one;
Change the shape’s height to a random value between 50 and 150;
Change the shape’s width to a random value between 50 and 150;
All of the operations could be undone using the Undo button.

And that is basically it. I know, as a graphics editor, this one sounds terrible, but it would be more than enough to demonstrate the purpose of the Command design pattern.

The main idea behind the implementation of the mentioned graphics editor is to separate the actual business logic of the button from its representation. To achieve this, each operation (request) of the button is encapsulated in a separate class object. Also, by using the Command design pattern, the implementation of undo operation is possible — since every command is encapsulated in a separate class, it is easy to store an objects’ list of already executed commands as well as undoing the last operation by taking the last command from the list and calling the undo() method on it.

Let’s check the class diagram first and then investigate each class/component to see how the Command design pattern could help us building such a graphics editor.

Class diagram

The class diagram below shows the implementation of the Command design pattern:

Command is an abstract class that is used as an interface for all the specific commands:

execute() — an abstract method that executes the command;
getTitle() — an abstract method that returns the command’s title. Used in command history UI;
undo() — an abstract method that undoes the command and returns the receiver to the previous state.

ChangeColorCommand, ChangeHeightCommand and ChangeWidthCommand are concrete command classes that implement the abstract class Command and its methods.

Shape is a receiver class that stores multiple properties defining the shape presented in UI: color, height and width.

CommandExample initializes and contains CommandHistory, Shape objects. Also, this component contains multiple PlatformButton widgets which have a specific implementation of Command assigned to each of them. When the button is pressed, the command is executed and added to the command history list stored in CommandHistory object.

Shape

A simple class to store information about the shape: its color, height and width. Also, this class contains a named constructor to create a shape object with pre-defined initial values.

Command

Commands

ChangeColorCommand — a specific implementation of the command which changes the color of the Shape object.

ChangeHeightCommand — a specific implementation of the command which changes the height of the Shape object.

ChangeWidthCommand — a specific implementation of the command which changes the width of the Shape object.

CommandHistory

A simple class that stores a list of already executed commands. Also, this class provides isEmpty and commandHistoryList getter methods to return true if the command history list is empty and return a list of command names stored in the command history respectively. A new command could be added to the command history list via the add() method and the last command could be undone using the undo() method (if the command history list is not empty).

Example

First of all, a markdown file is prepared and provided as a pattern’s description:

CommandExample contains CommandHistory and Shape objects. Also, this widget contains several PlatformButton components, each of which uses a specific function executing a concrete command. After the command’s execution, it is added to the command history list stored in the CommandHistory object. If the command history is not empty, the Undo button is enabled and the last command could be undone.

The client code (UI elements, command history, etc.) isn’t coupled to concrete command classes because it works with commands via the command interface. This approach allows introducing new commands into the application without breaking any existing code.

As you can see in the example, by triggering a specific command, its object is created, executed and added to the command history list. Hence, it is possible to undo the command even though it was executed several steps before — that’s one of the advantages of using the Command design pattern.

All of the code changes for the Command design pattern and its example implementation could be found here.

DEV Community: Mangirdas Kazlauskas 🚀

23 - Observer

Table of Contents

What is the Observer design pattern?

Analysis

Observer vs Mediator

Applicability

Implementation

Class diagram

StockTicker

Concrete stock ticker classes

Stock

StockTickerSymbol

StockChangeDirection

StockSubscriber

Concrete stock subscriber classes

Example

Your Contribution

22 - Mediator

Table of Contents

What is the Mediator design pattern?

Analysis

Applicability

Implementation

Class diagram

TeamMember

Concrete team member classes

NotificationHub

TeamNotificationHub

Example

Your Contribution

21 - Visitor

Table of Contents

What is the Visitor design pattern?

Analysis

Applicability

Implementation

Class diagram

IFile

File

Concrete file classes

Directory

Formatting extensions

IVisitor

Concrete visitors

Example

Your Contribution

20 - Chain of Responsibility

Table of Contents

What is the Chain of Responsibility design pattern?

Analysis

Applicability

Implementation

Class diagram

LogLevel

LogMessage

LogBloc

ExternalLoggingService

MailService

LoggerBase

Concrete loggers

Example

Your Contribution

19 - Flyweight

Table of Contents

What is the Flyweight design pattern?

Analysis

Applicability

Implementation

Class diagram

ShapeType

IPositionedShape

Concrete shapes

ShapeFactory

ShapeFlyweightFactory

Example

Your Contribution

18 - Builder

Table of Contents

What is the Builder design pattern?