|
Design
and patterns
The
process of identifying and documenting the emergence of patterns
to common problems is an art and science in itself. In fact,
even outside the realm of software engineering, we subconsciously
identify patterns for many of our daily activities, says MOHAN
BABU
The
global software development community is seeing signs of revival
after experiencing a slowdown in the past few years. And as
things start turning north, projects and IT enterprises are
looking to capitalise on some of the tools of productivity
that were refined even during the dotcom and tech meltdown.
One such development is the pervasiveness of design building
blocks, a.k.a. design patterns which help architects and software
engineers’ work towards developing optimal solutions speedily.
Most
of the techies will not need it but nevertheless, a brief
‘what and why’ of patterns: Every science and engineering
discipline has a common vocabulary to describe concepts and
to bring ideas together. In the field of information technology,
patterns are a way to document, define and resolve recurring
problems encountered throughout the software development process.
Design patterns are time-tested solutions to recurring software
design requirements. Patterns are given names and other properties,
and are expressed as a commonly recurring class structure
used to solve specific design problems.
In
an interesting article on “Business patterns for simple implementations,”
authors at IBM say “When business patterns and integration
patterns are combined to assemble solutions that perform complex
business functions, certain recurring pattern combinations
begin to emerge.” The key is to perhaps identify the emergence
of recurring patterns in commonly occurring problems.
This
process of identifying and documenting the emergence of patterns
to common problems is an art and science in itself. Designers
sometimes like to abstract patterns in common problems occurring
in their domain to aid in the process of designing solutions;
such abstractions can also end up as patterns. As a matter
of fact, even outside the realm of software engineering, we
subconsciously identify patterns for many of our daily activities.
Making tea or using a favourite recipe to bake a batch of
cookies is, in a sense, use of patterns; so is the process
of driving form one location to another.
Perhaps
among the most famous ‘must reads’ for those interested in
software design patterns is the book titled Design Patterns:
Elements of Reusable Object-Oriented Software, which interestingly
got the authors—Erich Gamma, Richard Helm, Ralph Johnson,
John Vlissides—almost a cult like following. The were called
“The Gang of Four.” Needless to say, for those interested,
there are a wide array of other books, articles and reference
material, both online and offline. Among the interesting portals
in my bookmark include http://hillside.net/patterns/. In a
way, patterns and pattern languages are ways to describe best
practices and good designs to capture experiences so that
it is possible for others to reuse it.
Though
the proponents of software patterns eulogise and almost create
a cult like following, even the best patterns are seldom used
in isolation. For instance, many designers concede that the
“Iterator” pattern is often used with the “Composite” pattern,
the “Observer” and “Mediator” patterns are generally used
together, and so on. There are times, when the problem in
question may not fit an existing abstraction of a pattern,
in which case the designer either uses multiple patterns in
conjunction or may even end up identifying a distinct pattern
of their own. Individuals who begin to design and program
with patterns, discover that the real art in using patterns
is knowing how to combine them.
Though
the process of designing and vetting patterns is an abstract
engineering process, getting to understand and effectively
use patterns is an art in itself. Joshua Kerievsky of Industrial
Logic, who runs a study group dedicated to design patterns
concedes: “Every now and then I ask people if they are familiar
with the book, Design Patterns: Elements of Reusable Object-Oriented
Software. On such occasions, I’m often surprised to hear someone
respond, “Yes, I’ve read it.” Having spent close to three
years running a study group devoted to understanding the subtleties,
combinations and variations of the patterns in this book and
others, I am often compelled to ask these individuals if they
actually believe that the book can be “read” rather than “studied”?”
An
interesting benefit of the wider adoption of standard design
patterns is that it helps technologists from around the globe
speak the same language. This is especially useful while managing
global and outsourced projects where a team gathers requirements
in one part of the globe and assists another team in a different
part of the world design and develop it into an IT solution.
Here it becomes imperative that the designers and architects
at both ends of the spectrum speak the same language; and
here by language, I don’t mean just English. Use of design
patterns may be yet another tool in an architect’s arsenal.
|
