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.