GoF Design Patterns Summary

GoF Design Patterns Summary

Design Pattern, is a general reusable solution to a commonly occurring problem within a given context in software design. Design patterns help you show the path how the similar problem was solved. Each Design Pattern should have a correct NAME, INTENT and MOTIVATION. Name of the Pattern help you understand what problem it is trying to address, Intent will help you dig deeper into it. Motivation of this pattern might help you understand the scenario / context when you can apply this pattern. There are too many patterns available in the industry they are broadly divided into these categories.

These are the categories of GoF Patterns( Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides). The best book to read about these Design Patterns is – Design Patterns: Elements of Reusable Object-Oriented Software written by GoF (Gang of Four).

Apart from these categories, we have different categories like Architectural patterns, concurrency patterns, Integration Patterns, J2EE Patterns etc.

Below is the quick reference of Design Pattern and It’s example and the keywords you should be able to remember to figure out the pattern. This list helps you easily figure out the pattern which you can apply in the scenario you are looking for.

Note: This notes is not for a person who doesn’t know Design patterns. This is more like a quick reference guide to refresh your Design patterns. I hope my notes would help you all.

Pattern Name Example Keywords to Remember
Creation Patterns
Family of Factories Different sub types
     – Factory Method  XML reader create No Dependencies in creation
     – Factory JDBC driver initialization Common Dependencies in creation
     – Abstract Factory ADO .net provider factory Sub type specific dependencies to create
Builder String and String buffer Different ways to create same object
Prototype Clonable Impl of java Clone / re use construction logic
Singleton Configuration Manager / Cache Manager Only one instance
Multiton HTTP Session Context specific singleton
Structural Patterns 
Adapter Java connector Architecture, Power Adapter, Display Adapter
SQL Data adapter in DB
Not compatible, Integration, External, conversion, 3rd party
Bridge DB Manager class using IDB connection instead of SQL Connection,
USB 2.0 specification, Mobile SIM interface
HTTP 1.1 specification (Browser /Web Server)
Permutations n combinations, specificatons
Composite XML tree Tree, Hierarchy
Decorator IO Streams, CSS styling Add more to Objects
Facade Controller in MVC, System/ Car startup, coffee vending machine, money transfer btw accounts, Orchestrator Co-ordination, Hide the complexity
Fly Weight Pool (Connection pool, thread pool etc) Re use fine grained Obj, pooling
Proxy Internet proxy server, Download Accelerator, web Service Proxy Add more to types, wrapper without breaking compatibility
Behavioral Patterns
Chain of Responsibility AC filters, Exception handling, supply chain management, event bubling, servlet filters, server.transfer in jsp pipe lined work, Hierarchical execution, do and delegate/fwd
Command  JDBC statement. execute(DML, DDL, DCL), struts actions in controllers  set of actions to be executed
Iterator For Each loop, Iterator interface impl, JDBC result set, Video Streaming, Agile development, paginated results Step by Step or phase by Phase
Interpreter Expression evaluation, Rule validation  lexical analysis ,Rule Engines
DB transactions, windows hibernate, restore points, backup and restore DB,
versioning systems, undo/ redo in word, back n fwd in browser
Maintaining State, Restore,
Distributed transaction coordinator, JTA/ JTS (java transaction) Real estate/ Stock brokers, controls communication between windows apps, bit torrents, chat clients/servers, iCloud to sync the data, mobile service providers
 Data Exchange with different formats
Observer DB triggers, fire alarms, mouse and keyboard Events, Eventing, notification
Strategy Collection uses comparable interface to compare different types of sorting, different types of credit card validation algorithms, different compression algos, Defining interfaces, stopping “what if” analysis
State Water object behaves differently in solid and liquid states, actors and roles, DB and TCP connections states, Bank A/c or Membership card state(gold,silver etc)
Changing behavior of an Object
          Avoiding if condition based logic
Template method Servlet life cycle Life cycle
Visitor GC of JVM  Repeated jobs with involvement of external components.


All your feedback is welcome.

Happy Reading 🙂


Understanding Software Design Principles

Understanding Software Design Principles

When any developer start writing code of any feature/module, the best practice is to try to formulate the high level Interfaces/classes and methods on a white paper / board and try to explain it to yourself why you have decided to have these methods and their parameters and the names of methods? what are the responsibilities of each method etc.

Once you convince yourself, it is very easy to convince others as you have the rational behind each and everything you defined. This is what is called “Designing”.  Designing doesn’t mean you have to draw the UML diagrams like Class Diagram, Sequence Diagram (I am not advocating you to avoid UML). Perhaps UML is the standard way to define the things, to be able to communicate the common understanding between distributed teams.

To Design your classes and Interfaces better there are many software design principles, very famous one is SOLID (expansion as below). Apart from this there are many principle many developers are not aware of, I am here trying to throw some light on those principle as well.

  • SRP     ( Single Responsibility Principle)
  • OCP    ( Open Close Principle)
  • LSP     ( Liskov Substitution Principle)
  • ISP      ( Interface Segregation Principle)
  • DIP      ( Dependency Inversion Principle)

SOLID principles are explained here, If you would like to have a quick recap.

SKY principles:

SKY is a name given by me,[don’t bother if you don’t like the name] I am just trying to use the word, which make sense.

  • SOC    ( Separation of Concerns )
  • KISS    ( Keep it simple, Stupid )
  • YAGNI ( You aren’t gonna need it )

These three principles are very very useful when you try to apply them in real time. So, lets try to discuss each one of them below in detail and if possible I will give you some example as well.

SoC (Separation of Concerns) :

This term was coined by Edsger W Dijkstra in 70 s, His idea behind this is just keep the separate things separately. You should keep the related things together and non related things separate. Let me put it in different terms, If you have to write a web page write HTML in one place, write CSS in another place and JS in different place. The reason behind doing this is each one has a different concern.

HTML focus on the text you would like to show on the page, here the concern is the what you want to show on your page. CSS focus on the style of the text you want to show like Font, size, color etc. Here the concern is How you are going to display the text of HTML. JS (Java Script) has a completely different concern to manipulate the DOM or Apply client side validations etc.  So, It is very easy if you separate the concerns with your business functionality, however this is a high level abstraction in the hierarchy. This intern brings the Single Responsibility, which you can apply very easily when you have a high level SoC.

If you don’t do SoC in early stages of the application, just imagine the HTML page with inline CSS and the JS written inline too. Can you maintain the code ?Can you read the code ? the answer I can guess is “NO”. So, these are the implications if you don’t do the SoC in the first place.

KISS ( Keep it simple, stupid):

This principle is started with a military systems design of US, they learned the systems should be as simple as possible to be maintained well. This has another meaning “Keep it Short and Simple” also. The idea you can easily get with this is you should design something only when it is needed 100%.

If you are trying to design Layers, I have seen some Architects who does too many Layers, and the reasons behind creating these layers will become absolute when the developers in the team changes. So, all these layers act as deli-gators with only line of code calling the next layer’s method.  This is a pure overhead. That is when you should apply KISS. Lets try to keep this things simple. 🙂

If you really need those layers document the responsibility of each layer correctly and communicate the same to the team. It is always better to keep the design simple, when the team changes we might not have to give a long KT (Knowledge transfers) sessions, when you have a simple design.

YAGNI ( You aren’t gonna need it ):

This is a awesome principle according to me, and very similar to KISS principle.  This principle forces you to think twice before you add any new behaviors to your objects. Do you really need this to the object ? Once you are satisfied with this answer, you could add them to that class. Usually when we ask these questions to our self, we might get the answer “May be this is not required here” or “We already have a similar method in another class” etc.

If we could implement this, we could save the development time, testing time etc, by NOT developing something which is not required. We won’t be doing over engineering the system because of this.

Hope this helped you, keep applying these principles in daily life

…. Happy reading 🙂

Reference for Design Principles is here.

Cloud Application Characteristics

Cloud Application Characteristics

The current buzz word in software industry is Cloud, most developers and QA’s does’t have correct understanding of “cloud application“. However, they say yeah we are also working on cloud applications these days. Even I was in this kind of mode for sometime, until our company started a challenge called “Seed the cloud”. I read a little more about the cloud architecture and how cloud applications should work.

Initially my biggest concern was, how to differentiate the normal web applications to Cloud applications.I hope, the below notes would help the people who are in the similar state.

Before understanding it’s characteristics, lets try to understand the definition of Cloud computing.

The Wikipedia definitions

"Cloud computing in general can be portrayed as a synonym 
for distributed computing over a network, with the ability
 to run a program or application on many connected 
computers at the same time. It specifically refers 
to a computing hardware machine or group of computing 
hardware machines commonly referred as a server 
connected through a communication network such 
as the Internet."
                                - UnKnown

Cloud computing is a model for enabling ubiquitous, 
convenient, on-demand network access to a shared 
pool of configurable computing resources (e.g., networks, 
servers, storage, applications, and services) that 
can be rapidly provisioned and released with minimal 
management effort or service provider interaction. 
   - NIST(National Institute of Standards & Technology, US)

Explanation: In the above explanation, If you observe the “__” words, they talks about distributed computing, network, Many connected computers, Internet. So, These are the important attributes in cloud computing. Then you might not see much difference between any regular web application and a cloud based application, Right ?

That’s the confusing part here…… If any application, satisfies any of these characteristics then that could be a Cloud application.

Note: All the characteristics are not required to satisfy,
 most of them should be satisfied.

The key characteristics of Cloud are below

  • On Demand, Self-service
  • Resource pooling
  • Rapid Elasticity
  • Measured Service
  • Broad Network Access

It’s time to understand what are the meanings of the above strings.


Self Service
Self Servic

On Demand, Self-service :

This title itself is very self explanatory. The resources should be on demand and User should be able to do the self service instead of depending on IT or other group.

Lets take some example to explain this,

Scenario: You need to add more hard disk capacity to your server because, your new feature is upload images of the customers might need more hard disk space.

Application Hosted on Regular Environment: You would normally raise a request to IT team to add new HDD of 100/200 GB to your server. Then your IT person would buy/get from warehouse and put this HDD in your server slot.

Application Hosted on Cloud Environment:  You would directly go to your cloud provider site/portal and ask for more GB space and they might charge you for each GB you use, that means instead of buying 200 GB today, you can simply buy 50 GB every month incrementally and pay for only the amount you have bought. The amount of GB you asked will be reflected in your account immediately. This is a example of On-Demand self service. Your cloud provider keep hardware ready for you when you need it.


  • Immediate Resource availability
  • Buy only what you need ( 50/100 GB instead of 500 GB HDD)
  • No dependency on IT/ other teams


  • Stick to the same Cloud provider (If you switch you might loose the data)
  • Might not get customization for Payment ( If provider charges on GB basis, you can’t ask him to charge on other basis, like per request.)

 Resource Pooling (Multi-tenency)

This is a also very straight forward concept, you  should be able to use the pool of resources.  Example could be processors, memory, RAM etc.  With the virtualization  platforms, we can use many  different machines out of one hardware machines.  Actually many different customers (users) might  share many hardware shared resources. This is  why the cost efficiency will come for small enterprises.

Scenario: Your application is very small and you are experimenting the product and you don’t have money to spend on hardware like Server, Racks, Cooling etc. The cloud provider would give all these things for very less money than you have to buy these things as he is sharing the resources among many different users. Only one server might be serving 4-5 customers as all their applications are very small.


  • Cost would be very less compared to own Infrastructure.


  • Risk of information leakage as the data might be stored on same server.
  • No information of Location of Storage of the data. ( If you have follow any country specific norms/regulations based on your application )



Rapid Elasticity ( Flexibility & Scalability )

Elasticity talks about the capability of providing or releasing the resources rapidly for scaling the applications. Which could be explained with example for easy understanding.

Scenario: You have a online shopping application and you sell cloths and accessories in this ekart. Your regular load on the server is 5000 requests per day and you announced a huge discount and did a huge ad campaign for the same on the occasion of X-mas. Now for these 10 days before 25th Dec you are expecting 25000 requests per day. How can you scale in regular Environment? You can simply add more processors / add new nodes with load balancing for only those 10 days dynamically based on your load and remove those servers after the offer period is over.


  • Very flexible to add / remove hardware
  • Cost effective (coz you didn’t buy anything)


  • None



Measured Services (Pay Per Use)

This means, user should be able to measure the resources (Storage, processing, bandwidth, number of Users) and their utilization in some metric. Resource utilization can be monitored and measured for use of both provider and consumer.

For example, You buy only 100 GB space and application hosting then you would only pay for 100 GB and the service charges, nothing more than that. This concept is called Pay Per use, but this is not a mandatory characteristic of cloud. In some cases this might not be applicable.


  • Cost Effective ( Pay only for the things you have used)
  • Easy scalability ( Increase when you need)
  • Provides Analytic data of your application ( Number of requests, number of accounts, data store capacity etc)


  •  Every cloud application might not be able to utilize this



Broad Network Access:

This means the applications can be accessed Anytime, Anywhere, Any Device. User has to have Internet, apart from that there is no restriction to access the application. This brings the user to all the devices like mobile phones, Tablets and Desktops.


  • Access Anywhere, Any Device
  • All you need is Internet.


  • No Internet, No Application.

Hope this gives an idea about – what is cloud ? and where it fits in your business scenarios.

Happy Reading 🙂