Male pattern boldness

Long time 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.

Copyright © Chet Haase. Originally published at Chet Haase's blog. Chet is an architect in the Java Client Group of Sun Microsystems, and spends most of his time working on graphics and performance issues. He is also co-author of Filthy Rich Clients: Developing Animated and Graphical Effects for Desktop Java Applications.