DEV Community: Lisa McCormack

Design Patterns - Behavioural

Lisa McCormack — Thu, 21 Oct 2021 11:11:28 +0000

Behavioural design patterns help us define manners of communication between classes and objects.

Chain of Responsibility Pattern

Problem - your program is expected to process different kinds of requests in various ways, but the exact types of requests and their sequences are unknown beforehand. The pattern lets you execute handlers in a particular order.

Solution - you define a chain of receiver objects that have the responsibility, depending on runtime conditions, to either handle the request or forward it to the next receiver in the chain. The request is sent down a chain of receivers withouth knowing which one handles the request.

Chain of responsibility pattern - Wikipedia
Refactoring Guru

The Command Pattern

Problem - you want to create commands that can execute and also undo. For example, you are building a text editor app that has different functionality like bolding the text, changing the font size etc. You have similar looking buttons that do different things.

Solution - the command pattern creates an object that encapsulates all information needed to perform an action or trigger an event at a later time. The command pattern creates a layer of separation between the UI and business logic by creating command classes that have single methods that is triggered by the UI object sending a request to it. The commands become a convenient middle layer that reduces coupling between the UI and business logic layers.

Refactoring Guru

The Interpreter Pattern

Problem - you need to process user input or convert information from one language into another. The language can be anything such as words in a sentence, numerical formulas or even software code.

Solution - you convert the souce information into an Abstract Syntax Tree (AST) of Terminal or Non-Terminal expressions that all implement an interpret method. A Non-Terminal expression is a combination of other Non-Terminal and or/ Terminal expressions. Terminal means terminated ie no further processing is involved. An AST root starts with a Non-Terminal expression and then resolves down each branch until all expressions terminate.

Interpreter Pattern. The Interpreter pattern helps to… | by Sean Bradley | Design Patterns In Python | Medium
Design Patterns - Interpreter Pattern

The Iterator Pattern

Problem - you need to access different collections of objects. Objects are usually stored in a list but you can have other more complex data structures.

Solution - you should extract the traversal behaviour of a collection into a separate object called an iterator. An interator object encapsulates all of the traversal details such as the current position and how many elements are left till the end so that several iterators can go through the same collection at the same time, independently of each other. All iterators must implement the same interface to make the client code compatible with any collection type. If you need a special way to traverse a collection, you just create a new iterator class, without having to change the collection or the client.

YouTube
Refactoring Guru

The Mediator Pattern

Problem - you have tight coupling between a set of interacting objects. Defining a set of interacting objects by accessing and updating each other directly is inflexible and it stops objects from being reusable and makes them hard to test. It should be possible to change the interaction between a set of objects independently.

Solution - the mediator design pattern promotes loose coupling of objects by removing the need for classes to communicate with each other directly. Instead of classes communicating directly, and thus requiring knowledge of their implementation, the classes send messages to a mediator object. The mediator object then transmits the messages to the other classes in a manner that they can interpret.

Mediator Design Pattern
Mediator pattern - Wikipedia

The Memento Pattern

Problem - you need to restore an object to its previous state

Solution - the internal state of an object is saved externally so that it can be restored to this state later. The memento pattern has three classes - originator, memento and caretake classes. The object (originator) is responsible for saving its internal state to a (memento) object and restoring to a previous state from a (memento) object. A client (caretaker) can request a memento (to save an internal state) from the originator and pass a memento back to the originator (to restore to a previous state)

Memento pattern - Wikipedia

The Observer Pattern

Problem - you need certain objects to receive an update when another object changes.

Solution - the observer pattern suggests you add a subscription mechanism to the publisher class so that individual objects can subscribe to or unsubscribe from a stream of events coming from that publisher. This mechanism consists of an array list for storing a list of references to subscriber objects and several public methods which allow adding and removing subscribers from that list.

Refactoring Guru

The State Pattern

Problem - state is a behavioral design pattern that lets an object alter its behavior when its internal state changes. It appears as if the object changed its class. You use this pattern instead of if/else statements or switch statements to change the state of your class.

Solution - the State Pattern says you create new classes for all the different states of an object. You extract all state specific code into a set of distinct classes. As a result you can add new states of change existing ones independently of eachother, reducing the maintenance cost.

Refactoring Guru

The Strategy Pattern

Problem - you have a class that does a specific thing but in a number of different ways.

Solution - you extract all the different algorithms into separate classes called strategies. The original class (context) must have a field for storing a reference to one of the strategies. The context delegates the work to a linked strategy object instead of executing it on its own. It often reduces long lists of conditionals and avoids duplicate code.

The Template Method

Problem - you have two or more classes with significant similarities and you want to reduce duplication.

Solution - to use the template method, you first see which parts of the algorithm are the invariant and which are different. The invariant steps are implemented in an abstract base class while the variant steps are given a default implementation or no implementation at all. The template method is used prominently in frameworks. Each framework implements the invariant pieces of a domain’s architecture, and defines ‘placeholders’ for client customisation options.

Template Method Design Pattern

The Visitor Pattern

Problem - you need to add new behaviour to existing classes without modifying it.

Solution - you place the new behaviour into a separate class called a visitor. The original classes are passed to one of the visitor’s methods as an argument. The visitor will have different methods for each class. In order to know what type of class it has been given and therefore the method to execute it uses a technique called double dispatch. Since the class we are passing as an argument to the visitor class knows what class they are, they can pick a proper method in the visitor class.

Visitor

Design Patterns - Creational

Lisa McCormack — Thu, 09 Sep 2021 10:40:10 +0000

Creational design patterns are responsible for efficient object creation which increases the flexibility and reuseability of existing code.

Factory Method Pattern

Problem - you want to create an object but you don’t know beforehand the exact type of the object your code should work with. You want to pass customisable objects to code that does not care about the details of that object, just that it implements the interface it expects. Say you have a company that delivers products by Truck. After a while your products become more popular so you want to start delivering by Ship. If you add other transportation types, your code could become more riddled with conditionals that switch the app’s behaviour depending on the class of transportation objects.

Solution - the factory method design pattern is used by first defining a separate operation, a factory method, for creating an object (called in this context a product),and then using this factory method by calling it to create the object. This enables writing of subclasses that decide how a parent object is created and what type of objects the parents contains. The factory method separates the product construction code from the code that actually uses the product. Therefore it’s easier to extend product construction code independently from the rest of the code.

Refactoring Guru
Factory Method Design Pattern
Factory method pattern - Wikipedia

The Abstract Factory Pattern

Problem - your code needs to work with various families of related products, but you dont want it to depend on the concrete classes of those products. The factory method constructs a single object and the abstract factory constructs multiple objects. It provides an interface for creating families of related or dependent objects without specifying their concrete classes.

Solution - declare interfaces for your different products and create concrete classes that follow these interfaces. Next declare an abstract factory interface and then concrete factories that implement this interface. Eg you have an MacFactory what will only create Mac products and a WindowsFactory that will only create Windows products.

YouTube
Refactoring Guru

The Builder Pattern

Problem - you need to create an object that has many optional and required fields. You can build a complex object step by step.

Solution - create a builder class that has different methods for each of the fields in the object you want to create and build your object step by step. The same builder can create different representations of the required object.

The Prototype Pattern

Problem - you want to create an exact copy of an object but some of the object’s fields may be private and not visible from the outside of the object itself. There are numerous potential classes that you want to use only if needed at runtime

Solution - the prototype pattern delegates the cloning process to the actual objects that are being cloned. The pattern declares a common interface for all objects that support cloning. This interface lets you clone an object without coupling your code to the class of that object. Usually that interface contains just a single clone method. An object that supports cloning is called a prototype. When your objects have dozens of fields and hundreds of possible configurations, cloning them might serve as an alternative to subclassing.

Refactoring Guru

The Singleton Pattern

Problem - you have information that needs to be shared in different parts of your application and your application needs one, and only one instance and you need to provide a global point of access to it.

Solution - the singleton pattern creates one single object that is shared around different resources in your application. It contains stored state that is global to your entire application. However, it can make testing difficult and creates coupling in different parts of your application.

YouTube
Singleton Design Pattern

Design Patterns - Structural

Lisa McCormack — Thu, 12 Aug 2021 13:15:56 +0000

Structural design patterns deal with the relationship between objects and how this can be simplified. It encourages you to create classes that accept interfaces rather than concrete classes so your code will be loosely coupled.

The Adapter Pattern

Problem - you need to get two incompatible interfaces to work together. You need to adapt a target class so that it has the same interface that a client expects. Any class can work together as long as the adapter solves the issue that all classes must implement every method defined by the shared interface

Solution - the adapter pattern defines a separate adapter class that converts the incompatable interface of an adaptee class into another interface the target client requires. The adapter class adapts the interface of an already existing class without changing it. The adapter class wraps the object to hide the complexity of the conversion happening behind the scenes.

YouTube
Refactoring Guru

The Bridge Pattern

Problem - you have a monolithic class that has several variants of some functionality that you want to divide and organise. Say you have a shape class with two circle and square subclasses and you want to extend the classes to incorporate red and blue so you end up with four subclasses: RedCircle, BlueCircle, Redsquare and BlueSquare. Adding new shapes and colours would make the hierarchy grow exponentially.

Solution - the bridge pattern lets you separate a large class or a set of closely related subclasses into two separate hierarchies - abstraction and implementation - which can be developed independently of each other. Instead of having all state and behaviours in one class, different dimensions (eg form and colour) are extracted into a separate class hierarchy. Colour related code can be extracted into subclasses (eg red and blue) and the shape class gets a reference field pointing to one of the color objects and this reference field acts as a bridge between colour and shape. The bridge pattern lets you split the monolithic class into several class hierarchies. After this, you can change the classes in each hierarchy independently of the classes in the others. This approach simplifies code maintenance and minimizes the risk of breaking existing code.

Refactoring Guru

The Composite Pattern

Problem - you have to implement a tree like object structure. Imagine you have two types of objects - products and boxes. The boxes can contain products as well as smaller boxes. These smaller boxes can contain products and even smaller boxes. If you had to calculate the cost of all items, iterating is difficult as each box object has nested levels.

Solution - the composite pattern suggests you work with products and boxes through a common interface. If you had to calculate total price of all products in all boxes, the compound shape passes the request recursively to all its children and sums up the result. The client code works with all objects through a single interface so it will not know if it is working with a simple or compound object. The client is not coupled to concrete classes.

Refactoring Guru

The Decorator Pattern

Problem - you want to add new functionality to an existing object without altering its structure.

Solution - you create a decorator class which wraps the original class. An interface is created and then concrete classes that implement this interface. You then create an abstract decorator class that also implements the interface and takes the concrete class in its constructor. A decorator can wrap other decorators.

Design Patterns - Decorator Pattern - Tutorialspoint
YouTube

The Facade Pattern

Problem - you have complicated code that you want hidden behind a front-facing interface.

Solution - the facade class is a wrapper class. To make a complex subsystem easier to use, the facade object provides a simple interface that masks the complicated interface of a subsystem. It improves readability and reuseability.

Facade pattern - Wikipedia

The Flyweight Pattern

Problem - you need to create a large number of similar objects. You can reduce memory usage by sharing objects that are similar in some way rather than creating new ones.

Solution - the constant data of an object is usually called the intrinsic state. It lives within the object; other objects can only read it, not change it. The rest of the object’s state, often altered from the outside by other objects is called the extrinsic state. The flyweight pattern suggests that you stop storing the extrinsic state inside the object. Instead, you should pass this state to specific methods which rely on it. Only the intrinsic state stays within the object, letting you reuse it in different contexts. Since the flyweight object (object containing only intrinsic state) can be used in different contexts, you have to make sure that its state can’t be modified. A flyweight should initialize its state just once, via constructor parameters. You can create a factory method that manages a pool of flyweight objects.

YouTube
Flyweight

The Proxy Pattern

Problem - you want to control access to an object and additional functionality should be provided when accessing an object. For example, when accessing sensitive objects, it checks that the client has the needed access rights.

Solution - a proxy is a wrapper object that is being called by the client to access the real serving object behind the scenes. The proxy can simply forward to the real object or can provide additional logic. For the client, usage of a proxy object is similar to using the real object because both implement the same interface.

Trunk based development

Lisa McCormack — Thu, 25 Feb 2021 11:48:54 +0000

Trunk based development is where all developers commit to the trunk, there are no branches. A team following TBD will pull from the trunk many times a day, knowing that the build passes. If you are developing a feature there are various ways such as feature flags or toggles to keep it hidden until it is ready to be presented to users.

You need:

Small story sizes: devs will break up a story into smaller sub-tasts so that when working on a change, it should only take a few hours before committing and pushing. Therefore commits are typically small.
Small build times: If build times are too big developers will be discouraged from committing often.

The benefits:

You will no longer encounter the problems with working on branches, those being:

Merge conflicts - imagine a team of developers each having their own branch, perhaps even more than one branch. This could easily result in merge hell. Merge conflicts means the developer needs to focus on the code of another developer as well as their own code.
Less visibility and communication. When working on branches you do not see the code that other developers have been working on until you merge your code in, leading to possible work duplication and/or you could break something unexpected once code is merged. Your code could even be incompatible with the code of another developer.

With TBD you are always release ready and this up-to-date state encourages more refactoring.

TBD goes hand in hand with continuous integration/ continuous deployment. In contrast to big stressful releases by frequently pushing to master this means that small improvements are continously being made to your live app. Smaller changes means smaller bugs that are easier to fix.