Differences and Similarities between Design Patterns and Architectural Styles

9 October, 2008 at 10:41 4 comments

Architectural styles[Def.] A pattern, from the French patron, is a theme of recurring events or objects, sometimes referred to as elements of a set. These elements repeat in a predictable manner. It can be a template or model which can be used to generate things or parts of a thing, especially if the things that are created have enough in common for the underlying pattern to be inferred, in which case the things are said to exhibit the unique pattern.

[Def.] Design, usually considered in the context of applied arts, engineering, architecture, and other creative endeavors, is used both as a noun and a verb. As a verb, “to design” refers to the process of originating and developing a plan for a product, structure, system, or component.

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems.

Not all software patterns are design patterns. Design patterns deal specifically with problems at the level of software design. Other kinds of patterns, such as architectural patterns, describe problems and solutions that have alternative scopes.

Example 1 : Singleton [Gamma95]

Rationalle and Motivation

The singleton pattern applies to the many situations in which there needs to be a single instance of a class, a single object. It is often left up to the programmer to insure that the An important consideration in implementing this pattern is how to make this single instance easily accessible by many other objects.


There is actually only one class that needs to be written specially to implement the Singleton pattern. A second client class will always be involved take make requests from the singleton.

[Booch Cloud]


Here is what a Booch [Booch94] class cloud might look like:


What are the advantages to using this pattern?

Single instance is controlled absolutely. When implemented as the pattern recommends, the class will have direct control over how many instances can be created. This is in contrast to making the programmer responsible for insuring that there is only one instance.

This pattern is easily extensible to allow a controlled number of “singleton” objects to be created. The most important modification needed to accomplish this change is in the operator that has control over access to the instances. In this case, the Instance() function would need to be changed.

Examples Here is how a generic singleton might be written in C++. If you want to try it, here is the source code: singleton_ex.tar

class Singleton {
    static Singleton* Instance();  // gives back a real object!
    static proof(void);            // proof that the object was made
    Singleton();                   // constructor
    static Singleton* _singleton;

And the implementation like:

Singleton* Singleton::_singleton = 0;

Singleton* Singleton::Instance()
   if (_singleton == 0)
      _singleton = new Singleton;
   }     // end if
   return _singleton;
}    // end Instance()

Food for thought…

What about sub-classing? How can we make the implementation more flexible? Possibly for reuse, or maybe for using multiple singletons in a single program. So what really happens if you try to explicitly declare a Singleton object?

Example 2 : Facade

Rationalle and Motivation

The facade pattern can make the task of accessing a large number of modules much simpler by providing an additional interface layer. When designing good programs, programmers usually attempt to avoid excess coupling between module/classes. Using this pattern helps to simplify much of the interfacing that makes large amounts of coupling complex to use and difficult to understand. In a nutshell, this is accomplished by creating a small collection of classes that have a single class that is used to access them, the facade.


There can be any number of classes involved in this “facaded” system, but I would think that the minimum is four classes. One client, the facade, and the classes underneath the facade. In a typical situation, the facade would have a limited amount of actual code, making calls to lower layers most of the time.


As stated before, the primary advantage to using the facade is the make the interfacing between many modules or classes more managable. One possible disadvantage to this pattern is that you may lose some functionality contained in the lower level of classes, but this depends on how the facade was designed.


Imagine that you need to write some program that needs to represent a building as rooms that can be manipulated. Manipulated as in interacting with objects in the room to change their state. The client that has ordered this program has determined that there will only be a need for a finite number of objects possible in each room, and a finite number of operations that can be performed on each of them.

You, as the program architect, have decided that the facade pattern will be an excelent way to keep the amount of interfacing low, considering the number of possible objects in each room, and the actions that the client has specified.

[Booch Diagram of a Facade]

Facade example

A sample action for a room is to “prepare it for a presentation”. You have decided that this will be part of your facade interface since it deals with a large number of classes, but does not really need to bother the programmer with interacting with each of them when a room needs to be prepared. Here is how that facade might be organised.

[Booch Diagram of a Facade]

Facade example

Consider the sheer simplicity from the client’s side of the problem. A less thought out design may have looked like this, making lots of interaction by the client necessary.

Architectural style

[Def.] Architectural styles classify architecture in terms of form, techniques, materials, time period, region, etc. It overlaps with, and emerges from the study of the evolution and history of architecture. In architectural history, the study of Gothic architecture, for instance, would include all aspects of the cultural context that went into the design and construction of these structures. Architectural style is a way of classifying architecture that gives emphasis to characteristic features of design, leading to a terminology such as Gothic “style”.

[Def.] The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them. The term also refers to documentation of a system’s software architecture. Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects.

[Shaw & Clements, 1996] “A set of design rules that identify the kinds of components and connectors that may be used to compose a system or subsystem, together with local or global constraints on the way the composition is done”

A set of constraints you put on your development to elicit desirable properties from your software architecture. Constraints may be:

  • Topological
  • Behavioral
  • Communication-oriented
  • etc. etc.

Architectural styles typically determine four kinds of properties [AAG93]:

  1. They provide a vocabulary of design elements – component and connector types such as pipes, filters, clients, servers, parsers, databases etc.
  2. They define a set of configuration rules – or topological constraints – that determine the permitted compositions of those elements.
  3. They define a semantic interpretation, whereby compositions of design elements, suitably constrained by the configuration rules, have well-defined meanings.
  4. They define analyses that can be performed on systems built in that style. Examples include schedulability analysis for a style oriented toward real-time processing [Ves94] and deadlock detection for clientserver message passing [JC94].

Example Architectural Styles

  • Model-View-Controller (MVC) architecture pattern. The MVC architecture style is a popular organizing concept for systems. The model represents the data for the system, the view represents the way the data are presented to the user, and the controller handles the logic for the system.
  • Publish-subscribe. The publish-subscribe architecture pattern is a system in which a publisher publishes data on a bus. Subscribers subscribe to portions of the data that are published by publishers on the bus. They register for various topics. When a message appears on the bus that matches the topic in which a subscriber is interested, the bus notifies the subscriber. The subscriber can then read the message from the bus.
  • Pipes and filters. Anyone who is familiar with UNIX systems will recognize this architectural pattern. The pipe and filter pattern allows a system to be assembled from small programs called filters. A filter has an input and an output. The filters are assembled into a chain in which each filter gets data from the previous filter in the chain, processes the data, and passes the data to the next filter in the chain. The best example of a pipe and filter system is a compiler. The lexical analysis, syntax analysis, semantic analysis, intermediate code generation, and optimization occur in a pipe and filter style chain.
  • Layers. A layered system is one in which different layers of the system take care of a specific function of the system. Each layer in a layered architectural style is a package of software that has a well-defined interface and a few well-known dependencies within the application. For example, a data access layer is responsible for encapsulating the technical means for accessing a database. All data requests to a database go through the data access layer for that database. The data access layer has the responsibility of hiding the data access mechanism from upstream layers. In a closed layer system, a layer may only access adjacent layers. In an open layer system, layers may access any other layer in the system, not just the ones to which they are adjacent.

Model-View-Controller (MVC) architecture pattern

Model-view-controller (MVC) is an architectural pattern used in software engineering. Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other. In MVC, the model represents the information (the data) of the application and the business rules used to manipulate the data; the view corresponds to elements of the user interface such as text, checkbox items, and so forth; and the controller manages details involving the communication to the model of user actions such as keystrokes and mouse movements.


MVC model

  • Model
    • The model represents enterprise data and the business rules that govern access to and updates of this data.
    • This is the domain-specific representation of the information on which the application operates.
    • It maps requests coming from clients into operations over the model
  • View
    • The view renders the contents of a model. It accesses enterprise data through the model and specifies how
      that data should be presented.
    • It is the view’s responsibility to maintain consistency in its presentation when the model changes.
    • MVC is often seen in web applications, where the view is the HTML page and the code which gathers
      dynamic data for the page.
  • Controller
    • The controller translates interactions with the view into actions to be performed by the model.
    • This responds to events, typically user actions, and invokes changes on the model and perhaps the view.
    • In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.

Differences and Similarities beetwen Architectural Styles and Design Patterns

There are many similarities between patterns and styles. Gaol: package engineering experience, formulation is the same : organization and interaction among “key” components. But thay have come from different communities. Many architectural styles have been well know for a long time in the software engineering community while patterns area relatively recent development in OO design . Figure below show a sketch of differences and similarities.


Differences and similarities


Bookmark and Share


Entry filed under: Architectural Styles, Design pattern, Software architecture. Tags: , , , .

Turing Test on six machine: Loebner Prize in Artificial Intelligence Se-Radio.net: Bran Selic on UML 2

4 Comments Add your own

  • 1. Nagaraj  |  9 January, 2009 at 11:53

    very good article. Liked very much. Good explanation of concepts in a simple way. I appritiate your hard work.

  • 2. Mahima  |  12 May, 2009 at 18:51

    This is really good and hope yo would write more on these topics… Good Work

  • 3. Ravindra Patil  |  11 November, 2009 at 08:39

    Design patterns

  • 4. Suratmih  |  15 February, 2014 at 14:29

    In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed

IT Passion’s Store



Get the Source
OSGi supporter
JUG Milano

Upcoming Events


Blog Stats

  • 328,400 hits

My PageRank

What's My Google PageRank?

%d bloggers like this: