CSC/ECE 517 Summer 2008/wiki3 5 rp

Pure Fabrication

Sometimes it is a good idea to introduce into a system an object that has no counterpart in the real world. This is called the pure fabrication pattern. Find examples of pure fabrication, and weave them into a narrative that can teach programmers when it is helpful and when it is not helpful to fabricate objects.

Background

All design patterns, regardless of their specific purpose, are born from the same basic principles. These principles include high cohesion, low coupling, and other features which result in flexible, maintainable, extensible code. Most often it is possible to separate the objects of an OO design into real world abstractions, or objects which reflect well known design patterns, such as a factory or an observer. Sometimes, however, the need for high cohesion, low coupling, and separation of dependence exists within software when there is no real world object representation or familiar design pattern to provide a solution. This is when pure fabrication is needed. Simply put, pure fabrication means creating a class object completely unrelated to the problem domain specifically for the purpose of achieving some degree of high cohesion, low coupling, potential for code re-use and high maintainability.

Pure Fabrication is often attributed to Craig Larman as part of his nine GRASP design patterns. Each of these patterns is similar to all other design patterns in that they strive to achieve code refactoring, decoupling, and reusability. Arguably, they are more generic than the GoF patterns, and pure fabrication is perhaps the most generic of them. In fact, pure fabrication is so generic that often existing well-known design patterns can be considered instances of Pure Fabrication.

Examples of Pure Fabrication

As mentioned above, several well known design patterns can be considered instances of Pure Fabrication. For example, Strategy and Command began as Pure Fabrications, but are common enough that a more specific name for each has been adopted. In a problem domain sense, they do not abstract a real world object. Each simply exists to promote decoupling between other objects in a system.

The Case Against Pure Fabrication

It is important not to overuse Pure Fabrication, or other design patterns for that matter, if it results in many small classes with too much interaction between them. Too much of this can actually cause unexpected coupling problems despite the intent to decouple objects. Further, this can increase the yo-yo effect (both vertical and horizontal) while reading source code. If code is spread among too many classes it can affect maintainability in a different, yet equally as negative way as tightly coupled code.

Similarly, sometimes it is OK to write code that has some degree of coupling, as there is always a trade off. In some cases, code does not necessarily need to be "pluggable" or compatible with all possible future uses and modifications of the code. It is important to realize this is a judgement call, and the design of the code and it's intent must be carefully analyzed. Code that is known ahead of time to have potential reuse obviously would benefit from using the priciples of Pure Fabrication and other design patterns, code such as framework code. However, if concessions are made in the design "just in case" future modification is needed, it may be good to re-evaluate the separation of responsibilities. Remember, re-factoring code in the future for maintenance reasons is not always bad, if it can be foreseen that the modifications are trivial compared to the cost of creating and implementing a very flexible, adaptable design.

External Links

http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx
http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx
http://www.google.com/url?sa=t&ct=res&cd=4&url=http%3A%2F%2Falcor.concordia.ca%2F~smw%2Fcomp354%2FL22web-2x2.pdf&ei=SdSJSLv8NYWshgTq6u1T&usg=AFQjCNFvKxZzrAps2Z0rGnTGdCrpvI3D6w&sig2=NdOWfIQrIPIIipsaaTZDFg
http://www.google.com/url?sa=t&ct=res&cd=9&url=http%3A%2F%2Fhebb.cis.uoguelph.ca%2F~dastacey%2FCIS3200%2FLectures%2FPDF%2FDesignPatterns3.pdf&ei=SdSJSLv8NYWshgTq6u1T&usg=AFQjCNEjBkMRZ_NhQpLp4zWjM9mlrBBhKw&sig2=S8iBydS82trn51IxSMbhbQ
Back to the assignment page