Chet Haase's Blog

Male Pattern Boldness

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.

Comments

• Excellent.

  Add to it the EJBB (Enterprise Java Black Beluga) pattern in which the beans float in the mush transparently provided by the Application Server and configurable by XML and you have the next billion dollar idea.

  Posted by: varan on October 25, 2007 at 08:47 AM

• People hate computer engineers when they think they're funny. But, hey, sometimes, they are :)

  Posted by: nopjn on October 26, 2007 at 09:19 AM

• Love this stuff. There's also the Aggrevator pattern in which selected APIs and Frameworks are slogged together to complete an application in two or three times the time and effort that it would have take to write the whole thing from scratch.

  Posted by: erikearle on October 26, 2007 at 01:01 PM

• Don't forget the Metadata Pipe Dream. By stuffing more and more metadata into a system and providing access to metadata the system can automagically figure out what it is supposed to do, how things are supposed to work together and bring world peace. Very popular in all sorts of "Enterprise" and "Framework" software.

  Metadata Pipe Dream is typically combined with the Reflection Reasoning Revanchist. The RRR is a software layer desperately using reflection to reason and gain back control over the information in the system and to restore "the old order" by messing around with system components one is not supposed to mess with.

  Reflection Reasoning Revanchist has recently found a match in the Annotation Anarchist. The AA is about ignoring 30+ years of tool development and re-inventing the wheel of preprocessing with a less flexible system, so what was previously code can suddenly become metadata, too.

  The above patterns are part of the General Magic class of patterns, which combine structural and behavioral patterns into wishful thinking patterns.
  

  Posted by: ewin on October 27, 2007 at 01:19 PM

• The Commando pattern in action http://www.javaperformancetuning.com/articles/commando.shtml

  Posted by: jacksjpt on October 31, 2007 at 05:24 AM

This work is licensed under a Creative Commons License.