uncyclopedia.org/wiki/Design_Patterns
copyright Design Patterns From Uncyclopedia, the content-free encyclopedia. Design Patterns abstract common software design principles into reusable patterns that should be applied where possible. All Patterns differ distinctively from each other and can be classified into different categories, Cremational, Destructural and Misbehavioral. However, implementations of design patterns normally do not appear isolated in large software projects, but are bungled (or merely con-fused) into conglomerates.
edit Abject Poverty The Abject Poverty Pattern is evident in software that is so difficult to test and maintain that doing so results in massive budget overruns.
edit Blinder The Blinder Pattern is an expedient solution to a problem without regard for future changes in requirements. It is unclear as to whether the Blinder is named for the blinders worn by the software designer during the coding phase, or the desire to gouge his eyes out during the maintenance phase.
edit Fallacy Method The Fallacy method is evident in handling corner cases. The logic looks correct, but if anyone actually bothers to test it, or if a corner case occurs, the Fallacy of the logic will become known.
edit ProtoTry The ProtoTry Pattern is a quick and dirty attempt to develop a working model of software. The original intent is to rewrite the ProtoTry, using lessons learned, but schedules never permit.
edit Simpleton The Simpleton Pattern is an extremely complex pattern used for the most trivial of tasks. The Simpleton is an accurate indicator of the skill level of its creator.
edit Adopter The Adopter Pattern provides a home for orphaned functions. The result is a large family of functions that don't look anything alike, whose only relation to one another is through the Adopter.
edit Flypaper The Flypaper Pattern is written by one designer and maintained by another. The designer maintaining the Flypaper Pattern finds herself stuck, and will likely perish before getting loose.
edit ePoxy The ePoxy Pattern is evident in tightly coupled software modules. As coupling between modules increases, there appears to be an epoxy bond between them.
edit Dependency Rejection The goal of this pattern is to reduce coupling. A male component sends a request to a female component so they can interoperate. The female component refuses the request with a lame excuse such as a buffer overflow error or a no such method exception.
edit Chain of Possibilities The Chain of Possibilities Pattern is evident in big, poorly documented modules. Nobody is sure of the full extent of its functionality, but the possibilities seem endless.
edit Absolver The Absolver Pattern is evident in problem ridden code developed by former employees. So many historical problems have been traced to this software that current employees can absolve their software of blame by claiming that the absolver is responsible for any problem reported.
edit Stake The Stake Pattern is evident in problem ridden software written by designers who have since chosen the management ladder. Although fraught with problems, the manager's stake in this software is too high to allow anyone to rewrite it, as it represents the pinnacle of the manager's technical achievement.
edit Tempest Method The Tempest Method is used in the last few days before software delivery. The Tempest Method is characterized by lack of comments, and introduction of several Detonator Patterns.
edit Visitor From Hell The Visitor From Hell Pattern is coincident with the absence of run time bounds checking on arrays. Inevitably, at least one control loop per system will have a Visitor From Hell Pattern that will overwrite critical data.
edit Unwanted Guest The Unwanted Guest pattern is the very useful idea of sideffects taken to extreme. This guest uses all kinds of under-the-cover mechanisms, such as reflection in Java, to modify the state of your program when you least expect it.
|