CSC/ECE 517 Fall 2010/ch7 7c ed

From Expertiza_Wiki
Jump to navigation Jump to search

Pure Fabrication

Pure Fabrication is a design pattern in which objects are created that do not correlate directly to real-world objects. This is generally used to achieve low cohesion and high coupling, as discussed in previous chapters. Although low cohesion and high coupling is an important design principle, fabricating objects that do not exist in the problem domain may lead to problems [1], thus classifying it as an anti-pattern.

Pure Fabrication is the second GRASP (General Responsibility Assignment Software Principles) principle covered in this chapter. All of these are general principles that "help aid developers in assigning responsibilities to objects" [2].

Example

Larman, the author of this design principle, provides an example of the Pure Fabrication pattern in his book Applying UML and Patterns. [3]

Scenario: A retail sales application contains the classes Sale and DatabaseA. The Sale class represents a purchase transaction, and DatabaseA is the database backend it is stored in.

With only these two objects, the Sale class would need to contain the logic required to persist a sale to the database, which violates high cohesion. If DatabaseA were to change, the Sale class would also have to change. This violates low coupling [4]. If the database were to change to DatabaseB, an adapter would be required, as visualized in Figure 1:


Figure 1

Instead, one could create a Broker class in the initial design that sits between the Sale and database, as in Figure 2 below:


Figure 2

The Broker would contain all the logic necessary to take the data from a Sale-like object and all the logic needed to persist that data in the database. Sale and other Sale-like objects would all interact with Broker in the same way and would not need to know about the database, thus achieving high cohesion. If the DatabaseA is replaced with DatabaseB, only the Broker class must change, thus achieving low coupling. Since there is no Broker concept in the problem domain, this qualifies as a Pure Fabrication.

Similar Patterns

Adapter

This is similar to the Adapter pattern, except for a few key differences. The Adapter pattern applies when a new class is created to sit in the middle of to two existing classes that interact, such as in Figure 1. This does not decrease coupling or increase cohesion. Instead, the Broker class is part of the initial design, and the Sale never has to know how to interact with a database [3].

Controllers in MVC

In the Model View Controller pattern, the Controller could be viewed as a Pure Fabrication, because it does not represent a concept in the problem domain. Instead, it is a layer that sits in between the Views and Models, allowing each to main high cohesion and low coupling [5]. MVC is such a common application of the Pure Fabrication principle that it has become its own design principle.

Disadvantages

In many cases, adhering excessively to the low cohesion principle makes things more complicated and harder to maintain. "Obviously if you are building frameworks and reusable components the idea of low coupling and coding to interfaces is important, but I have seen and done this myself in the past with custom / opinionated software as a 'just-in-case.' In more times than not, this just-in-case type of development leads to over-architected and hard to maintain software" [1].

References

  1. Hayden, David. Over-Architecting Via Pure Fabrication and Indirection to Reduce Coupling. 26 Aug 2006. http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx
  2. Hayden, David. Pure Fabrication GRASP Pattern - Software Design Patterns and Principles - Applying UML and Patterns - Domain-Driven Design. 18 September 2005. http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx
  3. Larman, Craig. Applying UML and Patterns: an Introduction to Object-oriented Analysis and Design and Iterative Development. Upper Saddle River, NJ: Prentice Hall PTR, 2005. Print.
  4. Cuellar, Ezequiel. Performing use-case realizations: The case for high cohesion and low coupling. 15 Jun 2007. http://www.ibm.com/developerworks/rational/library/jun07/cuellar
  5. Fowler, Martin. Passive View. 18 July 2006. http://www.martinfowler.com/eaaDev/PassiveScreen.html
  6. Wikipedia. GRASP (object-oriented design). 18 October 2010. http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)