Object Interaction Patterns: Facade

Li Zi Ying — Fri, 06 Nov 2020 02:45:40 +0000

What are object interaction patterns?

Object interaction patterns define how a set of objects interact and falls typically under 3 categories: creational patterns, structural patterns and behavioural patterns. These patterns are described below:

Creational patterns provide ways to instantiate single objects or groups of related objects
Structural patterns provide a manner to define relationships between classes or objects
Behavioural patterns define manners of communication between classes and objects

What is a Facade?

Facade pattern falls under the structural category, providing a simple and specific interface onto a group of complex objects. Similar to a facade in architecture, which is the outward facing appearance of a building, a facade serves as a front-facing interface, hiding the complex underlying code away from the client. The participants of the Facade pattern are as follows:

Facade delegates the client request to appropriate subsystem classes, allows only one way communication from facade to subsystem
Subsystems implement subsystem functionalities, does not know of facade
Client requests facade to perform an action

Benefits

Now, adding a facade interface means the client can use the facade to request for a certain action without directly calling the subsystem objects. This reduces complexity for client interaction as calls to the underlying code can be concentrated at one single point.

Having a facade also improves readability and usability, consolidating all the services as a single interface to make it more understandable. Creating facades also can allow you to define entry points to different levels of a subsystem. This also allows you to have loose coupling between subsystems by requiring them to only communicate through facades.

As such, facades can be very helpful in simplifying large complex systems where there are multiple subsystems tightly coupled to each other, which makes it hard for the developer to maintain the codebase and for future developers to read and understand the structure of the system as well.

Drawbacks

However, there can also be some drawbacks of the facade patten. By creating extra interfaces, more code is required to be maintained leading to a larger codebase.
This may not be so efficient for smaller projects as the increase in workload creating facades may outweigh the benefits mentioned in the previous section.

Real life example

An example where the facade pattern could be used is in the Key Word in Context (KWIC) problem system. The KWIC index system accepts an ordered set of lines, where each line is an ordered set of words and each word is an ordered set of characters. KWIC outputs a list of all circular shifts of all given lines in alphabetical order, where circular shifting is done by repeatedly removing the first word and appending it at the end of the line.

There are two main subsystems in the KWIC index system, namely the circular shift, which circular shifts each line, and alphabetizer, which arranges the final output in alphabetical order. These two subsystems ultimately create the output that the client wants, but the client does not have to know how exactly the output is formed. Therefore, as seen in the diagram, a facade can be used to separate the logical implementation of KWIC. The client only needs to know of the facade and the facade subsequently calls the various subsystems to get the final result through unidirectional communication, as shown by the single headed arrow.

Messaging Patterns: Pub/Sub

Li Zi Ying — Tue, 03 Nov 2020 07:45:23 +0000

Introduction

Messaging and message patterns are important parts of software development as they enable high-speed program-to-program communication with reliable delivery. Without it, services in the software will not be able to communicate with each other efficiently. This article mainly focuses on the publisher/subscriber message channel pattern.

Messaging and messaging patterns

Messaging in software engineering is typically asynchronous and used for inter-service communication. For software engineering, messaging patterns refer how services carry out messaging with each other, talking to one another through exchanging standardised messages over messaging channels.

Publisher/subscriber pattern

The pub/sub pattern is a message channel pattern, which connects the collaborating senders and receivers using a message channel that allows them to exchange messages. In the pub/sub pattern, senders are publishers and receivers are subscribers. In particular, the pub/sub mechanism removes the need for publishers to program the messages directly to specific subscribers. Instead, publishers can categorise published messages without any knowledge of subscribers and interested subscribers can subscribe to the categories of interest without any knowledge of the publishers.

Benefits

From the diagram, we can see that the publisher and subscriber do not need to know of each other, only knowledge of the event channel is needed and is sufficient to communicate. The benefit of this is that the components are loosely coupled, each publisher and subscriber can operate normally while independent of each other. This also provides scalability as publishers and subscribers can be scaled independently in the system without sending ripple effects across to the other components.

How is it applied in real life?

Pub/sub message pattern can be implemented through software like RabbitMQ, which is an open source message broker software or message-oriented middleware (MOM) that can be used irrespective of the language that the application is running on. In particular, RabbitMQ is able to support different kinds of messaging exchanges, including one-to-one direct messaging, pub/sub and broadcast types of exchanges. This flexibility makes RabbitMQ very popular and utilised by companies like Reddit, Trivago and Accenture.

The role of RabbitMQ is similar to that of the Event Channel in the first diagram, acting as a message broker to determine which messages are sent to which queues. The producer acts as the publisher, supplying messages to the broker (RabbitMQ) without any knowledge of the consumer or subscriber who consumes messages from the message broker. In the first diagram, the event channel simply acts as a message channel for subscribers to receive the message. However, for RabbitMQ, messages are not published directly to a queue. Instead, it provides an additional step, where the "Exchange" receives the message and routes it to a specific queue. This is done with the help of bindings and routing keys that will determine which queue the message will be added to. These messages then stay in their respective queues until the consumer handles the message.
The pub/sub pattern is clearly applied here as consumers and producers do not have to know of each other's existence, rather relying on RabbitMQ, a message broker, to help route the messages to their respective queues.

DEV Community: Li Zi Ying

Object Interaction Patterns: Facade

What are object interaction patterns?

What is a Facade?

Benefits

Drawbacks

Real life example

Messaging Patterns: Pub/Sub

Introduction

Messaging and messaging patterns

Publisher/subscriber pattern

Benefits

How is it applied in real life?