| What is a pattern anyway? |
In "Understanding and Using Patterns in
Software Development", Dirk Riehle and Heinz Zullighoven
give a nice definition of the term "pattern" which
is very broadly applicable:
|
"A pattern is the abstraction from a concrete
form which keeps recurring in specific non-arbitrary contexts."
|
| Within the software patterns community, the
notion of a pattern is "geared toward solving problems
in design." More specifically, the concrete form which
recurs is that of a solution to a recurring problem. But a pattern
is more than just a battle-proven solution to a recurring problem.
The problem occurs within a certain context, and in the presence
of numerous competing concerns. The proposed solution involves
some kind of structure which balances these concerns, or "forces",
in the manner most appropriate for the given context. Using
the pattern form, the description of the solution tries to capture
the essential insight which it embodies, so that others may
learn from it, and make use of it in similar situations. The
pattern is also given a name, which serves as a conceptual handle,
to facilitate discussing the pattern and the jewel of information
it represents. |
| |
| What is not a pattern? |
| Patterns are not: |
| |
Restricted to software design or Object-Oriented
design |
| |
Untested ideas/theories or new inventions
|
| |
Solutions that have worked only once
|
| |
Any old thing written-up in pattern format
|
| |
Abstract principles or heuristics |
| |
Universally applicable for all contexts
|
| |
A "silver bullet" or panacea
|
|
| |
| Why should I learn about Patterns? |
| Software Patterns are worth learning because
they: |
| |
Solve "real world" problems
|
| |
Capture domain expertise |
| |
Document design decisions and rationale
|
| |
Reuse wisdom and experience of master
practitioners |
| |
Explain "Best-fits" for the
given set of concerns/trade-offs |
| |
Form a shared vocabulary for problem-solving
discussion |
|
| Show more than just
the solution: |
|
context (when and where) |
|
forces (trade-off alternatives,
misfits, goals+constraints) |
|
resolution (how and why the solution
balances the forces) |
|
|
| |
| Why should I use patterns in the projects
I work in? |
For the same kinds of reasons that you should
reuse good code: Benefiting from the knowledge and experience
of other people who have put more effort into understanding
contexts, forces, and solutions than you have done or want to
do. Further, patterns can be more reusable than code, since
they can be adapted so that you can build software to address
particular special circumstances that cause you to be unable
to reuse an existing component.
Patterns also give developers common sets of names and concepts
for dealing with common development problems, thus enhancing
communication.
|
| Are patterns specific to a particular
vendor, platform, object model, technology , programming language
? |
| No. |
| |
| How do you call a pattern ‘good’? |
| A good pattern does the following: |
| |
It solves a problem:
Patterns capture solutions, not just abstract principles
or strategies. |
| |
It is a proven concept:
Patterns capture solutions with a track record, not theories
or speculation. |
| |
The solution isn't obvious:
Many problem-solving techniques (such as software design
paradigms or methods) try to derive solutions from first
principles. The best patterns generate a solution to a
problem indirectly -- a necessary approach for the most
difficult problems of design. |
| |
It describes a relationship:
Patterns don't just describe modules, but describe deeper
system structures and mechanisms. |
| |
The pattern has a significant
human component: All software serves human comfort
or quality of life; the best patterns explicitly appeal
to aesthetics and utility. |
|
| |
| What are Anti-Patterns? |
| If a pattern represents a "best practice",
then an anti-pattern represents a "lesson learned."
There are two notions of "anti-patterns." |
| 1. |
Those that describe a bad solution to
a problem which resulted in a bad situation. |
| 2. |
Those that describe how to get out of
a bad situation and how to proceed from there to a good
solution. |
|
| A good Anti-pattern also tells you why the
bad solution looks attractive (e.g. it actually works in some
narrow context), why it turns out to be bad, and what positive
patterns are applicable in its stead. they try to go a step
further by recommending a course of action for correction, recovery,
and prevention. |
| |
| How are Architectural Patterns different
from Design Patterns? |
An architectural pattern expresses a fundamental
structural organization or schema for software systems. It provides
a set of predefined subsystems, specifies their responsibilities,
and includes rules and guidelines for organizing the relationships
between them.
|
| A design pattern provides a scheme for refining
the subsystems or components of a software system, or the relationships
between them. It describes commonly recurring structure of communicating
components that solves a general design problem within a particular
context. |
| |
| How are patterns different from Algorithms
and Data Structures? |
Certainly, algorithms and data structures may
be employed in the implementation of one or more patterns, but
algorithms and data structures generally solve more fine-grained
computational problems like sorting and searching. Patterns
are typically concerned with broader architectural issues that
have larger-scale effects. The design patterns address people
and development issues like maintainability, reusability, communicating
commonality and encapsulation variation. These are issues that
matter to the people who need to create and evolve/grow these
software systems over time.
|
Algorithms and data structures are usually
concerned almost exclusively with optimizing space or time or
some other aspect of computational complexity and resource consumption.
They are about finding the most compact and efficient means
to perform some important computation or store and recall its
results. Such algorithms and data structures are rarely concerned
with compromises and tradeoffs related to issues like maintainability
and adaptability and (re)usability of the architecture.
|
This is why algorithms and data structures
tend to be more fine-grained than patterns: Because they mostly
address issues of computational complexity, and not so much
the underlying issues of the people who are both using and building
the software. Patterns fundamentally address people issues (like
maintainability) more so than simple hardware and software efficiency/memory
issues.
|
| Of course software developers need to be concerned
both with finding appropriate architectures and with finding
appropriate solutions to computational problems. So there will
always be a need for patterns as well as for algorithms and
data structures (and their use together). |
| |
| What is the link between Patterns and
Frameworks? |
A framework is a set of cooperating classes
that make up a reusable design for a specific class of software.
A framework provides architectural guidance by partitioning
the design into classes and defining their responsibilities
and collaborations. It will define the overall structure, its
partitioning into classes and objects, the key responsibilities
thereof, how the classes and objects collaborate, and the thread
of control.
|
A framework predefines these design parameters
so that you, the application designer/implementer, can concentrate
on the specifics of your application. The framework captures
the design decisions that are common to its application domain.
Frameworks thus emphasize design reuse over code reuse, though
a framework will usually include concrete subclasses you can
put to work immediately. A developer customizes a framework
to a particular application by sub-classing and composing instances
of framework classes.
|
A single framework typically encompasses several
design patterns. In fact, a framework can be viewed as the implementation
of a system of design patterns. Despite the fact that they are
related in this manner, it is important to recognize that frameworks
and design patterns are two distinctly separate beasts: a framework
is executable software, whereas design patterns represent knowledge
and experience about software. In this respect, frameworks are
of a physical nature, while patterns are of a logical nature:
frameworks are the physical realization of one or more software
pattern solutions; patterns are the instructions for how to
implement those solutions.
|
| In comparison with frameworks, Design patterns
are more abstract, are smaller architectural elements and less
specialized than frameworks. |
| |
| What is a Pattern Language? |
| A collection of patterns forms a vocabulary
for understanding and communicating ideas. Unlike a mere pattern
compilation or catalog, a pattern language includes rules and
guidelines which explain how and when to apply its patterns
to solve a problem which is larger than any individual pattern
can solve. These rules and guidelines suggest the order and
granularity for applying each pattern in the language. A pattern
language may be regarded as a lexicon of patterns plus a grammar
that defines how to weave them together into valid sentences
(or artful tapestries if you will). |
| |
| What is the difference between a pattern
and a class? A reusable component? A parameterized (template)
class? A class library or package? A framework? A tool? A code
generator? |
A pattern is not an implementation. It describes
when, why, and how to go about creating an implementation or
other engineering product.
|
| Some (not many) solutions are amenable for
description via implementations (as classes, frameworks, tools,
or whatever) that provide developers with just about everything
they would need to know or do. Even so, the code itself is not
the pattern. |
| |
| What is the difference between a pattern
and How - To guide? |
| The solution described in a pattern may be
phrased as a series of steps similar to those seen in How-To
guides and cooking recipes. But again these steps form only
one aspect of a pattern. Also, patterns aspire to greater scope
and generality of context, and greater authoritativeness in
identifying and resolving forces than seen in typical How-To
guides. |
| |
| Can anyone create and write patterns? |
| Writing good patterns is not easy. Patterns
should not only provide facts (like a reference manual or user's
guide), but should also tell a story which captures the experience
they are trying to convey. A pattern should help its users to:
comprehend existing systems, customize systems to fit user needs
and construct new systems. The process of looking for patterns
to document is called ‘pattern mining’. |
| The best way to learn how to recognize
and document useful patterns is by learning from others who
have done it well! |
| Further assistance for those who wish to to
write a pattern, or a pattern language, may be found in Ward
Cunningham's "Tips for Writing Pattern Languages",
and in Gerard Meszaros' and Jim Doble's "A Pattern Language
for Pattern Writing". Both of these papers are indispensable
resources for writing patterns and pattern languages. |
| |
| How do I start implementing patterns
in .NET? |
| In MSDN Online, Three patterns – Factory,
Singleton
and Observer
– are explore in detail in the context of implementation
in .NET. |
| A question you may have is “ Has Microsoft
employed any patterns while making the .NET Framework class
Libraries“ ? For MSDN Architect registered members, here
is a Presentation
that describes some of the patterns that were used in the making
of .NET Framework in Microsoft Website. Also, Read the article
titled Use
Proven Solutions to Solve Common Design Problems for a discussion
on patterns and .NET. |
| Also recommended is the viewing of the webcast
titled “Using
Patterns to Build Business Applications”. |
| |
| Are patterns over-hyped? |
| Of course. It is impossible to avoid! |
| |
| Any good books On Patterns ? |
| |
Design Patterns: Elements
of Reusable Object-Oriented Software by Erich Gamma, Richard
Helm, Ralph Johnson, and John Vlissides (frequently referred
to as the Gang of Four or just GoF). |
| |
Pattern-Oriented Software Architecture:
A System of Patterns (also called the POSA book) by Frank
Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad,
and Michael Stal (sometimes called the Siemens Gang Of
Five or just GoV); |
| |
A Pattern Language:
Towns, Buildings, Construction, Christopher Alexander
, Oxford University Press, 1977 |
| |
Pattern Languages of Program
Design (PLoPD1) Coplien and Schmidt (editors);
Addison-Wesley, 1995 |
| |
Patterns of Software:
Tales from the Software Community Richard Gabriel; Oxford
University Press, 1996 |
| |
Analysis Patterns:
Reusable Object Models, Martin Fowler; Addison-Wesley,
1996 |
| |
Pattern Languages of Program
Design 2 (PLoPD2) Vlissides, Coplien, and Kerth
(editors); Addison-Wesley, 1996 |
|
Pattern Languages of Program
Design 3 (PLoPD2) Martin, Riehle, and Buschmann
(editors); Addison-Wesley, 1997 |
|
Object Models: Strategies,
Patterns, & Applications Peter Coad with David North
& Mark Mayfield; Prentice Hall, 1995 |
|
| |
| Any good Sources on the Net? |
|
|
| |
Author: K.
Meena, Director, Symbiosis Training and Consultancy
Pvt. Ltd, Bangalore
|
 |
Meena leads the design,
development and delivery of Corporate Training workshops
in the domains of Technology and Technology Management.
She has a lot of industry experience in architecting,
designing and managing large applications.
She conducts high-end workshops and seminars and offers
consultancy on .NET, COM+, Middle-tier technologies, Architecture,
Data Warehousing etc.She is a regular speaker in Microsoft
forums like Professional Developers' Conference, TechED
, Architect Summit, DevDays etc.
E-mail:
meena@symindia.com |
| |
|
|
