Skip to main content

Male Pattern Boldness

Posted by chet on October 25, 2007 at 8:03 AM PDT

Longtime readers of my blog will know that
I'm a huge fan of Design Patterns. Patterns wrap complex architectures with simplistic
descriptions. They create wonderful
buzzwords that we can use instead of resorting to actual
human language descriptions. And they help enforce that feeling that we're all
a part of an elite clique shunned by society not by
their choice, but by ours.

So it is with much happiness and joy (refer to the Joyous Configuration
pattern for more background on this emotion) that I hereby announce more
patterns to help the software community in the tedious and underappreciated lives
that we lead.

Refactory

The Refactory pattern, a spin-off of the earlier
Factory
pattern, is useful for engineering teams that
enjoy the infinite redesign
cycle of software. While the code may work perfectly well in some configuration,
chances are great that the entire code base can be completely refactored to
have the same functionality, but with different class hierarchies,
indenting styles, and naming
conventions. This pattern provides for such standard refactoring methods as
arbitraryRename(),
codeRestyler(), classHierarchyFlattener(), and
classHierarchyExpander(). This
single pattern is often credited with being the cornerstone of
our entire industry.

Delicate

The Delicate pattern, like the traditional
Delegate
pattern,
is signified by its extreme use of indirection and object layering,
where a successful
implementation will be comprised of so many layers of API and object
wrappers that the final result is apt to break easily and
nondeterministically.
As Chris Campbell
pointed out to me, the Delicate pattern is a critical part of the trendy
Fragile Programming
methodology.

Obliterator

The Obliterator pattern is a combination of the
Iterator pattern,
which is useful for walking
through a list of objects, and deletion functionality. When applied to any list
of objects,
it automatically walks the list and deletes all members, then removes the list,
the calling function, and the application itself. Variations of the pattern
have been known to also destroy the operating system, the computers
running the system, the networks on which the pattern is deployed,
and the universe in which the pattern exists. Use with care, or at
least ask your users to test it for you before declaring the product final.

Veneer

The Veneer pattern is a thin, attractive wrapper on top of a
rat's nest of spaghetti code. The pattern is similar to its forerunner,
the Façade pattern,
except that it avoids the use of special internationalized
letters that make correct spelling difficult for English programmers.

Disfunctional

Contrary to the related
Functional Design
pattern, the Disfunctional
pattern requires every component of a system
to know about and perform every possible operation. Variants of the
pattern exist, such as the Gossip and Nosey Parker patterns.

Lethargic Initialization

Like the
Lazy Initialization
pattern, the Lethargic Initialization
pattern delays creation and calculation
until such time as it is needed. However, the Lethargic pattern
adds the additional requirement
that operations be carried out slowly, if at all, and may not
actually complete when the
information is needed by the system. This approach has
distinct advantages over the Lazy
pattern. Systems using the Lethargic approach can never suffer the
performance hit that is possible with
the Lazy pattern, because at no time is the system actually doing much,
if any, work.

Single

Like the Singleton
pattern, the Single represents objects of
which there is only
one instance in the system. However, the Single pattern has the important
distinction that its objects are constantly on the search for
other objects to combine with, in a desperate attempt to avoid
being stuck on their own. A Single object will
print any line, tell any recursion tail, or go into any foo bar as it
tries to pair off with other Singles.

Cunning Plan

Like the earlier Strategy
pattern, the Cunning Plan pattern cleverly
selects the implementation of
an algorithm on the fly. However, this more radical approach automatically
selects the most devious and subversive methodology, designed to
undermine the entire system from within.

It's clear that there are many more patterns that we can invent if
we just set our minds to the task and find appropriately obscure
words with which to name them. But hopefully the selection above will invigorate
the community to begin implementing brave new architectures based
on proven, robust buzzwords.

Related Topics >>