Design pattern & pattern language

Software development as a field has significantly gained in maturity and became a well-defined and structured domain where some best practices, rules and methods have been designed and enhanced. During the last years an important boom has been noticed in different disciplines related to the programming and software development in general. The OOP played a major role in this success with the new models of designing and programming, developers were able to conceive a very complex solutions which responded to not only users requirements but also the continuously growing business needs (Buschmann.et.al, 2007).
As important as the programming languages and technics, developers have noticed that there are some common and recurrent problems for which they have to deal in each project and the need of having some methods that describes solutions for common problems raised. In 1987, during the famous OOPSLA conference, Kent Back and Ward Conningham presented their idea of design pattern.

What is Design pattern?
A pattern describes a recurrent problem in our environment, which occurs again and again. It than describes a core solution that can be used many times even for different contexts (Gamma.et.al, 2009). The term pattern is not specific to computing or any field; it can be used in different situations. Focusing on the used of design pattern in software development, it is important to highlight that it is not a technical implementation of a solution and is independent of any programming language or platform, The design pattern describes the problem for which it applies, why this is an important and recurrent problem? And it gives a template of how the solution should be designed. It might also describe the forces and contexts where the problem/solution applies.

Different design patterns have been developed and discussed and a big community is working on the enhancement and design of new patterns. Depending on the problem or context, we might chose to use on or another design. However the complexity of certain problems we might combine different design patterns in the same solution and this is known as the pattern language.

What is pattern language?
A pattern language consists of a hierarchy of parts linked together by patterns, which solve generic problems (Olson, 2008).

Pattern language for distributed computing
Distributed systems are Omni-present in our lives, companies are building their business around systems that might be geographically dispatched and containing different component each responsible of a part of the system. The distributed systems have some specifications compared to ‘classical’ ones as:
– Asynchronous calls
– Concurrency
– Availability
– Heavy load …etc.

In all distributed systems, we might face some recurrent problems or situation for which well-designed pattern languages have already been created and enhanced. One of the problems I will consider here is the Event demultiplexing and dispatching.

Event demultiplexing and dispatching

Scope of problem
Distributed systems are considered event-driven systems; they receive different stimulus and events both from internal and external components or actors and they are supposed to deal and response to these events in respect of certain conditions (Buschmann.et.al , 2007).

Challenges
Two main situations should be considered in this scenario
a. Asynchronous events: The events must be handled correctly and the system should able to process specific requests even if under heavy load. This might be related to some real-time process where the actor cannot accept responses longer than a specific time scale.
b. Simultaneous events: The system can be under heavy load and requests or events in general might arrive simultaneously, the system should be able to receive all these events and handle them properly

Patterns abstract 
Two important patterns seem to be appropriate for this scenario where the system should deal with the two key events of demultiplexing and dispatching.
a. Reactor pattern: allows the system to demultiplex and dispatch events from different requests that are delivered to applications from one or more clients.
b. Proactor pattern: allows the system after competing the process of the asynchronous call to dispatch responses to clients (Buschmann.et.al , 2007).

Figure 1 : Simple representation of the use of both patterns to from one pattern language.

The use of multiple patterns in the same solution to form one pattern language designed to solve more complex problems requires some rules especially interfacing between the different patterns and it might also overcomplicate the implementation, however we can be sure that we entire the best of both patterns (Gamma.et.al, 2009).

References:

– Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (2009). Design Patterns: Elements of Reusable Object-Oriented Software. ISBN:0-201-63361-2.

– Frank Buschmann, Kevlin Henney, Douglas C. Schmidt (2007). Pattern-Oriented Software Architecture: A Pattern Language for distributed computing, Volume 4. ISBN: 978-0-470-05902-9.

– Daren Olson (2008). Teaching Patterns: A Pattern Language for Improving the Quality of instructions in higher education settings. UTAH State University.