Software Design Principles and Patterns – In Brief

Hi Friends,

In this post, I am going to give you a brief information regarding the design patterns used in Software Architecture Process. For any software designing process, selecting a particular set of patterns is very essential. Once the patterns are finalized, then development team can proceed with the implementation using stable and robust architecture.


Before actually jumping on to the design patterns, we must first see what design principles are and should be followed:

  1. One and Close Principle ( Open for Extension, Closed for Modification )
  2. Prefer Delegation over Inheritance
  3. Single Responsibility Principle
  4. Interface Segregation
  5. Program to Interface rather than implementation ( Similar to Polymorphism )

There are basically three category of design patterns. These are designed by the GOF ( Gang of Four ). They are as follows:

  1. Creational Patterns
  2. Structural Patterns
  3. Behavioral Patterns


  • Factory

This pattern is used to get the objects of the same level of hierarchy. We have a factory which provides the required instances of the classes based on the need.

Examples: Iterator, DriverManager.getConnection() etc.

  • Abstract Factory

This pattern is used to get the concrete objects of the same family. We have one abstract factory interface which is implemented by multiple concrete factory’s and thus, producing the required objects.

  • Prototype

When most of the attributes of the objects are similar (only 1 or 2 are dissimilar) then we use this kind of pattern. In this pattern, we don’t make a simple copy of the object. We basically do a memory to memory copy (shallow copy) of the object which is quite faster. (This is done by clone() method).¬† To do a deep copy of the objects (recommended), it is necessary to implement Cloneable (for custom objects) and not primitives.

Example: busManager.clone() etc.

  • Builder

When we want to one big object based on different small objects, then we use Builder Pattern. It has a Director which calls the build method inside Builder to build the object. Builder is basically an interface which is implemented by all it’s concrete builders and thus, their specific build method is called.

  • Singleton

When we want¬†one or limited¬†instances of the class, then we use Singleton pattern. It is comparable with Mono-state class (which has all methods static). But in Singleton pattern, all methods are object based and it’s constructor is private.


  • Facade

This pattern provides a simple method or methods for the user to access the complete system functionality. Different types of façade are Optional Facade and Mandatory Facade.

Examples: Web Services, Connect and Disconnect of the most complicated System etc.

  • Adapter

When we want to have a compatibility between interfaces of different packages, then Adaptor is provided. Class Adapter and Object Adapter are the different types of this pattern. Object Adapter is used as it deals with objects are redundancy of the attributes is very less as compared to Class Adapter.

There is a single way adaptation possible using one adapter. If we need both way adaptation, then two separate adapters are needed.

Examples: MouseEventAdapter, ListAdapter etc.

  • Bridge

This pattern is used to decouple the interfaces of the system. The main purpose of Bridge pattern is to decouple abstraction from implementation.

Examples: MVC patterns, 3 layer architecture etc.

  • Decorator

Decorator as the name suggests provides the extra functionality to the existing feature. It decorates the given object based on the user selections. Decorator class has ‘has-a’ and ‘is-a’ relationship with interfaces.

Examples: ReadLine() function (It internally uses Read function and using the decorator, provides reading line by line) etc.

  • Composite

When we want to apply one action to it’s child and when parent and child are on the same type, then we use Composite Pattern.

Example: Storage Units like Folder and File. Operations like select, deselect, copy, cut, paste can be applied to them and delete on folder also deletes all the files it contains.

  • Flyweight

It is used to reduce the memory space. When unique no. of objects are very small as in comparison with total no. of objects, then Flyweight pattern is used. The objects are immutable.

Example: String Class.

  • Proxy

It is just like a surrogate/ placeholder to the main object. The different types of the proxy pattern are Virtual Proxy, Remote Proxy, Protection Proxy and Smart Reference Proxy. In real, Lazy Initialization is always preferred over proxy.


  1. Template

When basic structure is needed for the different classes, then template pattern is used. It also provides the consistency, usability between different pages. There is a final method which is acting as structural method and other methods are primitive methods.

Example: Thread.start() is a template method which internally calls run() method of Thread class.

  • Chain of Responsibility

It follows the workflow model and also uses¬†the segregation of responsibilities. Handler interface (having HandleRequest() method) is used which is implemented by multiple Concrete Handler’s. It has a successor.

In this, the object is encapsulated into a request object.

Two things that need to be kept in mind before using this pattern are 1) Chain should not be broken. If any new developer forgets to call successor, then it will create problems. So, use Template pattern with this approach. 2) There should be a fixed end.

  • Observer

If there is one or more dependency on one object, then Observer pattern is used. It is also called as ‘Publish/Subscribe’ pattern.

Example: Implementations of Event Listener in Java, C# etc.

  • Command

In this pattern, the request object is encapsulated and passed to invoker. Invoker then processes the request object and executes the command. The encapsulation of the request object is same as we discussed in Chain of Responsibility pattern.

  • State

When we want an object to alter its state based on behavior, then State pattern is used. The state objects can be shared and can be implemented as Singletons.

In this pattern, the state transition occurs frequently which is not the case with Strategy pattern (We will discuss this later in strategy pattern)

Example: Traffic Lights etc.

  • Strategy

When there are many ways to go from one point to another point, then use strategy and perform the action. User selects strategy at the start.

When we compare this pattern with State pattern, state transition occurs very frequently but the strategy once decided continues to be one till application processing lasts. It captures the abstraction in an interface and buries implementation details in derived classes.

Strategy is basically an algorithm which is exchangeable and vary independently.

Example: Game levels (Normal, Hard, Extreme), Comparator, compare method is used in Collections.sort().

  • Memento

In this pattern, the reference to the main object is maintained. The encapsulation should not be broken. Caretaker should not tamper with the states. This pattern preserves encapsulation boundaries.

  • Visitor

This pattern works on the different hierarchies of products. This fits best in for the requirements which are quite ad-hoc and not permanent.

This pattern lets you define a new operation without changing the classes of the elements on which it operates.

  • Iterator

This pattern provides the best way to iterate on the collections without showing/representing it’s underlined representation.

Suppose we have a hash set and contains many null values inside it, then use HashSet iterator which skips the null values internally and only provides only valid values.

Example: Iterator class in Java, Enumerator in C# to iterate over the collections.

  • Mediator

This pattern define an object that encapsulates how a set of objects interact. It reduces coupling between objects by keeping them from referring to each other explicitly.

Example: Web Server for Chat Room which handles communication between participants.

  • Interpreter

This pattern is just the use of the composite pattern to represent the grammar. The interpreter defines the behavior while the composite provides the structure.

Example: JVM has an interpreter which compiles the code based on the OS.

Now, we have seen what all patterns we can use to design the software. It is also important to think about what can be the things we should not do while designing patterns. These things are basically called as ‘Anti-Patterns‘.

Let’s take a look at each one of them on the group hierarchy level.

  • Development Anti-Patterns
  1. Boat Anchor
  2. Cut and Paste Programming
  3. Dead End
  4. Fire Drill
  5. Functional Decomposition
  6. Golden Hammer
  7. Mushroom Management
  8. Coding Bad Smells
  • Architectural Anti-Patterns
  1. Death Match Project
  2. Analysis Paralysis
  3. Corncob
  4. Death by Planning
  5. Irrational Management
  6. Project Mis-Management
  • Management Anti-Patterns
  1. Architecture By Implication
  2. Auto generated Stovepipe
  3. Intellectual Violence
  4. Jumble
  5. Spaghetti Code
  6. Swiss Army Knife

You can also refer following links to get more information about the design patterns, examples and their implementation.

@MsWizKid Signing off,

Enjoy ūüôā

Software Architecture Patterns – Introduction

Hi Everyone,

I am currently¬†pursuing Masters from BITS Pilani. In the second semester exam, I had a subject named – ‘Software Architectures’. For a ‘serious’ software developer, this is an awesome subject to study and get masters on!


I am going to share some of the vital topics from this subject¬†which will definitely help you in creating / understanding software architectures and it’s process¬†easily!

Begining with, there are various ways of developing an architecture. It depends upon the organization’s way of approaching a solution, problem and architect’s way of handling the problems. We will see different architecture pattern types after going through Architecture Business Cyclle ( ABC ).

Architecture Business Cycle:


Software architecture is a result of technical, business, and social influences. Its existence, in turn, influences these technical, business, and social environments. This cycle of influences from the environment to the architecture and back to the environment is called the Architecture Business Cycle.

This cycle provides the details of stakholders of the¬†System, overall architect’s¬†experience, requirements quality attributes and their¬†influence on the environment.

Below are ‘some’ of the architecture technique ( styles ):

1)   Pipes and Filters 


         Examples of this architecture are: Unix Shell Programs and Compilers

Main Characteristics:

1) No data sharing
2) Do not know upstream / downstream filters
3) Correctness does not depend on order of incremental processing


1) Often reduces to batch processing system
2) Difficult to support interactive applications

2)  MVC ( Model View Controller )


             Model Рrefers to data model
¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬† View¬†‚Äď refers to external views or presentation of data.
¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬† ¬†Controller¬†‚Äď refers to module relating reactions of view or presentation to changes in data.

3) Broker



1) Location Transparency

2) Changeability / Extensibility of components

3) Portability (of client and server)

4) Portability (of brokers) & Interoperability (among brokers)

5) Reusability


1) Overheads ‚Äď Performance Loss

2) Lower fault tolerance

3) Developmental issues (Testing / Debugging)

@MsWizKid signing off,

Enjoy ūüôā