Design Patterns

"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."

"Each pattern is a rule which describes what you have to do to generate the entity which it defines."

The notion of a "pattern" was first introduced by the architect Christopher Alexander in his seminal works [1] [2] [3] on architecture. Alexander was interested in showing how standard solutions to recurring problems in architecture could be solved and the importance of the right "fit", or "goodness of fit" as coined by Alexander. With this we mean that the solution fits well to the context and environment in which it will exist. For instance, in architecture there may be a rule that states that all rooms should have windows, however depending on the function of the room it may be desirable to place the window on different walls. If the function of the room is as a sleeping room then it may not be desirable to place the window so that the sun shines directly in the room in the afternoon and evening. Likewise it may be considered a "good fit" that the window is positioned so that sunlight shines in the room in the morning. Thus we see that although there is a guiding design heuristic, all rooms must have a window or source of natural light, there may be multiple solutions with their applicability governed by the practical use and function intended for the room. This is the very same concept that drives "design patterns" in software as well. One desires a solution to a functional problem and many design patterns may resolve this issue. How does one then proceed to choose the correct pattern from the selection available?

Christopher Alexander attempts in his book "The Timeless Way of Building" to show why this quality that is the root of design patterns cannot be given any definite nomenclature. It is "the quality with no name", and positions itself between many descriptions, all of which almost capture the essence of the quality. Almost. A few of the words Alexander uses to describe the quality are worth mentioning since they illustrate the reasoning behind design patterns.The following section gives my interpretation of the underlying meaning of a selection of these words Alexander puts forth in his work.

Alexander states that "the word that we most often use to talk about the quality without a name is the word "alive" (p.29) - alive is descriptive of a pattern, because the pattern must be "energetic", although the phrase energetic is not any better a description than "alive", on the contrary it is more precise but less meaningful in [terms of software]. But what one means with energetic is that the pattern solution must have a certain vibrance about it, it should not be considered a cold, monolithic structure that is numbly applied. It should generate excitement, it should be a solution of such goodness and advantage that it goes beyond resolving a functional design problem, it should also inspire. Alexander argues that this word is not adequate because it is merely a metaphor, it cannot be used to explain something definitive. Although one may know the difference between alive and dead, there is a different intangible meaning of the word "alive" that is only a metaphor; a metaphor for a behavior or feeling.

Another word that Alexander applies to this quality is the word "whole" (p.31), however this word is not sufficing either, because with it comes the connotion of self-containment; "it suggests closure, containment, finiteness" (p.31), which "undermines the quality that has no name" (p.32). In tems of a software design pattern I find this word to be strongly descriptive of what one should search for in a pattern. Or more precisely what constitutes a required property of a pattern. A good solution is not automatically a pattern, it must fullfil certain criteria. One of these is it must be "whole", with this one means that it must resolve all its inner forces, they should exist in a state of equilibrium; but for our use the equilibrium although balanced, must not necessarily nullify itself. One might then ask - how can a system of forces be in balance if they do not nullify themselves? I argue that balance in our context is that the internal forces of non-functional requirements should be balanced in such a way that no single force is strongly dominant. It means that the application of the pattern should not increase or decrease the efficacy of any single force by magintudes of order relative to the other forces; both of the pattern itself and of the system as a whole.

A third term that we shall investigate is the expression of "exact" (p.34); which further examines the resolution of internal forces and their equilibrium. Alexander asserts that "if the adaptation to the forces is not perfectly exact, there can be no comfort, no freedom, because the small forces which have been left out will always work to make the system fail" (p.34). With this Alexander means that one must acknowledge the existence of these forces, and one must handle them carefully. If one fails to do so the equilibrium will never be reached, and thus the pattern will never become. A good solution must be aware of its limitations - because there is no such thing as a perfect solution because of context. It may fit perfectly to one situation, but the fact that it resolves this specific situation perfectly makes it less and less suited to resolving other situations existing in different contexts. So the qualifying condition is that the pattern must actively, and thus precisely, resolve its inner forces, its interior form must be precise and exact; at the same time it must be loose and flexible in its exterior form in order to accomodate differing contexts.

It is from these selected apriorisms about the quality one seeks that we continue our work with patterns.

Motivation behind their use

"Designing object-oriented software is hard, and designing reusable object-oriented software is even harder "

The question poised in the preceeding section provides in itself the motivation for the existence of patterns. Because it is just that we need to establish, although, superficially, design patterns are mainly used to resolve functional issues they do also play a very important role when considering the non-functional characteristics of a system. So the question remains, how does one select the appropriate pattern from a set of functionally equal alternatives? This is, as in the case of architecture, where one must consider the context and environment in which the functional operation will execute. If it is in a constrained environment, e.g. a mobile device with limited capacity, then do not select a pattern that heavily tolls the CPU or memory, or other resource. More concretely, this could disencourage the use of patterns that rely on frequent disc access, reflection, highly refactored and fragmented code (as this would take longer to load and be heavier to run on a mobile device due to many objects existing in memory at the same time), as opposed to a solution with fewer classes and memory space reuse. Here we see that the environment and context will, when considering mobile and limited devices, too a far greater degree govern which system design is appropriate. This motivates the use of design patterns when developing mobile information systems.

Types of design patterns

There are many different categorizations of design patterns, however on this site we will use the categorization offered by the founding fathers of design patterns for software [4]. These categories are:

Creational: Details design patterns that are used to create objects, albeit not in a straight-forward fashion. The importance of this in the context of mobile-information systems is when one uses a service oriented approach, wherein mobile clients connect to a remote service provider (server). Maybe there have been upgrades or new functionality has been added on the server but the mobile clients are not aware of this. Thus there is a need for the clients to be able to call a "generic" create method and be returned an object that is updated/suits their capabilities.

Behavioral: Offers design patterns that are used to alter the behavior of the system, either at the client or server side.

Structural: These are patterns that quite often lean more to the architectural side of things, as they outline the overall structure of a system, however they may also exist at lower levels of abstractions where there may be a need for a certain structure in parts of the system in order to ensure a given functionality, or non-functional characteristic is sustained.

Additionally a pattern is described through an ontology, Christopher Alexander defined a set of constructs for describing a pattern - this ontology has been adapted and tailored by the software community to better represent patterns for software use. The GoF [4] express a selection of constructs that at the very minimum should be present when describing a pattern; thus the following can be though of as notions that must be present in some form in any sound pattern description:

Pattern name - is a common denominator of both GoF and Alexander. Both outline the difficulty of finding appropriate and apt names for a pattern.

Problem - is a description of the when to apply the pattern. There are two parts to this description, namely the problem itself and the context in which the given pattern applies. Both Alexander and GoF acknowledge this fundamental difference.

Solution - in the software context it is a description of the artefacts that make up the solution, in object-oriented terms it describes the composition of the solution through the classes, interfaces, packages, etc. that may be involved in resolving the given problem and context. However, the solution is not concrete - it is not an idiom - it describes in an abstract manner the solution. The implementation may vary dependant on the technical platform or variants of the context.

Consequences - this section describes the costs and trade-offs that accrue when applying the pattern - and are the most critical factor to be considered when deciding on different design solutions. Essentially they describe how the given pattern may affect the non-functional requirements of the system; e.g. portability, flexibility, extendabilty, performance, complexity - etc.

Above are listed the abstract constructs that comprise a sound design pattern description - these constructs will be consolidated in the section "Design Pattern Format"

This page will provide comprehensive information about various design patterns and their applicability and use in mobile information systems. The patterns will be categorized and discussed in terms of their respective non-functional tradeoffs. The patterns will be mainly design patterns at various levels of architectural granularity. However, the page will not present any idioms, or technology bound solutions. Most patterns will be presented with accompanying Java implementaiton examples and tutorials.

Pattern Space

A pattern space is a collection of design patterns that are well suited to a given domain. There are many examples of existing pattern spaces, but none of them consider the idiosyncracies of mobile information systems. Part of this PhD work will do exactly this.

Design Patterns

Design Patterns

What are Design Patterns?

Motivation behind their use

Types of design patterns

Pattern Space

References