This paradigm is sometimes referred to as ‘Tell, don't ask’, meaning tell the object what to do, don't ask about its state; and sometimes as ‘Ask, don't tell’, meaning ask the object to do something for you, don't tell it what its state should be. Either way around the best practice is the same — the way an object should perform an action is that object's concern, not the calling object's. Interfaces should avoid exposing their state (e.g. via accessors or public properties) and instead expose ‘doing’ methods whose implementation is opaque. Others have covered this with the links to pragmatic programmer.

This rule is related to the rule about avoiding "double-dot" or "double arrow" code, often referred to as ‘Only talk to immediate friends’, which states foo->getBar()->doSomething() is bad, instead use foo->tellBarToDoSomething(); — if foo is responsible for managing bar, then let it do so!

This paradigm is sometimes referred to as ‘Tell, don't ask’, meaning tell the object what to do, don't ask about its state; and sometimes as ‘Ask, don't tell’, meaning ask the object to do something for you, don't tell it what its state should be. Either way around the best practice is the same — the way an object should perform an action is that object's concern, not the calling object's. Interfaces should avoid exposing their state (e.g. via accessors or public properties) and instead expose ‘doing’ methods whose implementation is opaque. Others have covered this with the links to pragmatic programmer.

This rule is related to the rule about avoiding "double-dot" or "double arrow" code, often referred to as ‘Only talk to immediate friends’, which states foo->getBar()->doSomething() is bad, instead use foo->doSomething(); which is a wrapper call around bar's functionality, and implemented as simply return bar->doSomething(); — if foo is responsible for managing bar, then let it do so!