Tell, don't ask. Law of Demeter

Whenever you talk to a good, experienced programmer, they will tell you that "loosely coupled" classes are very important to good software design.The Law of Demeter (LoD) or Principle of Least Knowledge is a design guideline for developing loosely coupled software, particularly object-oriented programs.

Law of Demeter for functions requires that a method M of an object O may only invoke the methods of the following kinds of objects:

1. O itself
2. M's parameters
3. any objects created/instantiated within M
4. O's direct component objects
5. a global variable, accessible by O, in the scope of M

Example

The following Java coded illustrated this law:

public class LawOfDemeterInJava
{
  private Topping cheeseTopping;
  
  /**
   * Good examples of following the Law of Demeter.
   */
  public void goodExamples(Pizza pizza)
  {
    Foo foo = new Foo();
    
    // (1) it's okay to call our own methods
    doSomething();
    
    // (2) it's okay to call methods on objects passed in to our method
    int price = pizza.getPrice();
    
    // (3) it's okay to call methods on any objects we create
    cheeseTopping = new CheeseTopping();
    float weight = cheeseTopping.getWeightUsed();
    
    // (4) any directly held component objects
    foo.doBar

  }

  public void badExamples(Pizza pizza)
  {
    // (5) Not OK. We are calling coock() on Cheese object
    cheeseTopping.getCheese().cook();

    // (6) Not OK
    Slice slice = pizza.getSlice();
    slice.decorate()
  }

  private void doSomething()
  {
    // do something here ...
  }
}

Impact on testing.

Following this law have a huge impact on your code testability. When It comes to unit tests you faces the problem of instantiating of dependencies on class under test (CUT). Whether you choose mocks or stubs (to be consistent with terminology refer to Wikipedia or other developers source)to test you CUT, following Demeter laws significantly decrease amount of instantiation code you need to write for your tests.