“Only talk to your immediate friends”
Let’s get one thing clear- we are making software- not looking for enlightenment
In Software development- sometimes ignorance can be bliss.
The lesser your class knows- the less complicated it will be.The more it knows- more it has to worry about.
Lets start with an example
I have a class OrderManager. This class is responsible for Order creation.
It calls another class- OrderValidator- who is responsible for Order validation -i.e. whether the order is good to go or not. There could be many validations that need to be done. e.g. ( A) whether the input is correct. (B) Do we have enough inventory ? (C) Can we deliver the order by the date requested?
Now all these tasks may in turn be done by different classes- because you wouldn’t want to overload one class with multiple responsibilities.
So we end up with three classes
OrderManager- who oversees the complete operation
OrderValidator who gives a go ahead for the order creation. It will in turn call another set of classes to take this decision.
InventoryValidator – who validates the inventory
Now lets talk about “friends”
OrderValidator is a friend of OrderManager
InventoryValidator is a friend of OrderValidator
As long as Ordermanger is not aware of the existence of InventoryValdiator- you are following this rule
However if we expose the InventoryValidator to OrderManager- you are guilty of breaking the rule
Code Example I – Following the rule
class OrderManager
{
…
public void createOrder ()
{
orderValidator.validateOrder();
}
…
}class OrderValidator
{
…
public validateOrder (Order anOrder)
{
inventoryValidator.validateInventory (order.getRequestedAmount());
}
…
}
Example II Breaking the rule
class OrderManager
{
…
public void createOrder ()
{
orderValidator.validateOrder();
inventoryValidator= orderValidator.getInventoryValidator()
inventoryValidator.validateInventory (order.getRequestedAmount());
}
…
}class OrderValidator
{
…
public validateOrder (Order anOrder)
{
}public InventoryValidator getInventoryValidator ()
{
return inventoryValidator ;
}
…
}
Why do we have this rule ?
Like I said earlier on- the less you know the better you will be.Consider the previous example.Lets say down the road the Inventory Management got more complex and you need to look at a dstributed inventory .Now the Order creation process hasn’t really changed. We are still checking for inventory- the only difference we are checking inventory in more places or in a different fashion
If we have designed the system as per the first example- you will not see any change made to the OrderManagement system- but the second system will almost definately impose a change on the OrderManagement
What can we do to follow this rule ?
Any method in your class can invoke only the following types of methods
A) Methods in the same class.
B) Methods on the parameters to the method
C) Method of the objects that were instantiated in the method
D) Method of the objects owned as member of the class
If you follow the above- you will be a true protector of this rule
But isnt this too restrictive?
It sure is and takes lots of discipline to follow it. And like any other priciple- its a friendly guideline.
And who do we thank for this?
NorthEastern University.
Recent Comments