GOF Design Patterns — conclusion

Avijeet Dash and Satyabrata

Dash

Now that we have 23 known patterns behind us, It’s time to recollect and

find out where we stand. We started with the idea of how to improve the
object-oriented software development. We realized it’s critical to achieve

reusability of code as the requirements grow. The 23 GOF Design patterns helped

us discipline our thoughts and change the way we think and communicate. Now we

say ‘ How about using strategy here’, ‘why not make a decorator out of

these functions’, ‘Let’s factor a Template Method here’. Now each line

communicates what otherwise would have taken hell lot of time to explain and at

the end no consensus in understanding could have been guaranteed. Now that we

all understand and appreciate the place of Design of patterns in application

development, lets take a look at how they are related and how we should organize

our memory to remember them.

Abstract Factory, Factory Method and Prototype tell us how not to

create objects directly by using their class name rather to go via a factory

object. That will keep us safe from future changes that might be needed to

create other kind of objects.

Chain of Responsibility and Command teach us how not to commit to

specific operations for satisfying requests. By avoiding hard-coding requests it

makes it easier to change the way requests get handled.

Abstract Factory and Bridge suggests solution when we have

dependence on hardware and software platforms. To make applications port easily

to a different platform these patterns suggest solutions.

Hiding the object representation and implementation issues from the client

keeps changes from cascading. Abstract Factory, Bridge, Memento and

Proxy do that for us.

To keep the objects dependencies on algorithms neat, it’s required to

encapsulate the algorithms into separate objects. That keeps the frequently

varying part of the application separate from the not-so-frequently varying

part. Builder, Iterator, Strategy, Template Method, State, Template method and

Visitor all provide that useful reusability and loose coupling.

Tight Coupling leads to monolithic code that difficult to understand and

change. The functionalities should be threaded in such a non-monolithic manner

that they can be used almost like pluggable pieces. Loose coupling is pioneered

by Abstract Factory, Bridge, Chain of responsibility, Command, Façade,

Mediator and Observer.

Object Composition over Inheritance is so much favored in so many of these

patterns and they make great flexible extensible systems. Bridge, Chain of

responsibility, Composite, Decorator, Strategy, State, Visitor all preaches

Object Composition.

Adapter, Decorator, Visitor gives us a solution when the source code for

the software may not be available and we need to extend the functionality.

Diagram for the relationship among the patterns

Target for Refactoring

Refactoring is the art and science of improving the existing code. Typically

when an application development starts it starts with prototyping that is

to see if things work. Then when requirements grow the same code is tailored,

tampered and hacked to add the new functionality. With the growing need for

change the software unless scaled to greater strengths turns out to be lump of

spaghetti code that becomes a nightmare to manage. Refactoring is what is

done to the code developed at Prototyping time to remain useful at expansionary

and consolidating stages. Refactoring tells how to organize the code, how

to extract methods, how to introduce new classes. Where to break away

inheritance and where to use object composition? Refactoring often ends up in

implementing one or the other design pattern. All of us have got what is called

the ‘gut feeling’ where the code stinks, and that is place for refactoring.

So while developing code the earlier we smell the code and refactor the easier

it is to go ahead. Standard Refactorings give us that ‘power of fear’, where

and how to refactor to fix ‘code smells’.

The Roadmap - J2EE Patterns

Now that we are rich with the GOF Design Pattern knowledge, we need to go

ahead and see what other work is going on in this space. And a major work is

done by Sun Microsystems, hatching 15 J2EE Patterns. The J2EE

Patterns are based on J2EE framework and gives us great ways to architect our

JSPs, Servlets and EJBs and Java Codes. The 15 patterns are evenly dived for 3

tiers as presentation, business and database related

patterns. Sun Microsystems also advocates best practices and refactoring for

J2EE applications developed for any application server.

We will doing a case study of each of the J2EE Patterns next in this

tutorial. Here is an Invitation and a partying thought. We are thankful to all

our readers who keep encouraging us by sending in their questions and feedbacks.

( The diagram is contributed by CF Wong)

(The authors are working as Senior Developers at MindTree

Consulting Pvt. Ltd.)