Difference between Pure fabrication and Indirection

Question

I was trying to find tutorials and good examples which would explain difference between those two, but not able to find any information.

Pure fabrication and indirection acts to create and assign responsibilities to intermediate object, so could anyone explain what is difference between those design patterns?

Thanks!

Answer 1

You use Indirection if you want to create a lower coupling between components. The example Larman suggests in Applying UML and Patterns is a class TaxCalculatorAdapter. In order to shield clients from having to know inner workings of a possible adapter, he hides them with an indirection, only exposing the required API. This Indirection will be highly coupled to the adaptees, but only loosely coupled to the clients.

The PersistentStorage from Pure Fabrication is indeed an Indirecton (Larman states so in the book) in that it provides lower coupling. Pure Fabrication goes beyond that though in that it creates objects that are not part of your Domain Model.

The example Larman gives is a domain class Sale. Since Sale has all the data to save, it would be a candidate to hold the logic for saving a Sale as well (Information Expert). However, persistence logic is not related to the concept of a Sale, hence the class would become incohesive. Also, by coupling the Sale to a particular DB API, you limit reuse (Indirection to the rescue). And because saving is a general activity, you would likely also duplicate code in objects which also need to be saved. To avoid this, you make something up (the pure fabrication), meaning you create something that is not part of the Domain model (here: a PersistentStorage), but still captures an essential activity in your application.

As such, Pure Fabrication it is a specialization or rather a variant of Indirection.

Answer 2

Pure fabrication and indirection both are principles from GRASP. Following examples in this dzone article might clear your concept about pure fabrication and indirection.

Pure Fabrication:

We know the domain model for a banking system contains classes like Account, Branch, Cash, Check, Transaction, etc. The domain classes need to store information about the customers. In order to do that one option is to delegate data storage responsibility to domain classes. This option will reduce the cohesiveness of the domain classes (more than one responsibility). Ultimately, this option violates the SRP principle.

Another option is to introduce another class which does not represent any domain concept. In the banking example, we can introduce a class called, PersistenceProvider. This class does not represent any domain entity. The purpose of this class is to handle data storage functions. Therefore PersistenceProvider is a pure fabrication.

Indirection:

This principle answers one question: How do you cause objects to interact in a manner that makes bond among them remain weak?

The solution is: Give the responsibility of interaction to an intermediate object so that the coupling among different components remains low.

For example, a software application works with different configurations and options. To decouple the domain code from the configuration a specific class is added - which shown in the following listing:

Public Configuration{
  public int GetFrameLength(){
    // implementation
  }
  public string GetNextFileName(){
  }
 // Remaining configuration methods
}

In this way, if any domain object wants to read a certain configuration setting it will ask the Configuration class object. Therefore, the main code is decoupled from the configuration code.

If you have read the Pure Fabrication Principle, this Configuration class is an example of pure fabrication. But the purpose of indirection is to create de-coupling. On the other hand, the purpose of pure fabrication is to keep the domain model clean and represent only domain concepts and responsibilities.

Many software design patterns like Adapter, Facade, and Observer are specializations of the Indirection Principle.