* still in an early stage
* still in an early stage
Each module has a set of responsibilities so there is a kind of mapping between them. This mapping can be good or bad. A module is said to be an expert for a given responsibility if it already has the necessary information which is necessary to fulfill the task. IE now says that responsibilities should be mapped to modules such that each module only is responsible for things it is an expert for.
Another view on the principle is that responsibility mapping is bad when one module has to ask another module for information (getter invocation), makes some computations, and stores back the result (setter invocation). Rather modules should tell other modules what they should do and not patronize them. In object-orientation objects can be seen as entities constantly claiming “I can do that myself!”.
The following reasoning shows that Tell don't Ask and Information Expert are essentially the same principle:
Awhich gets data from another module
Band makes some computations or decisions which normally
Bis the information expert and not
A, so IE is neglected.
Despite of its proof-like form this is not a formal proof as there is no formal definition of TdA and IE. Nevertheless TdA and IE can be seen as two views on the same principle.
When this principle is not adhered to, then a module has a responsibility for which it is lacking some information. So in order to fulfill the task the module has to first acquire the needed information by invoking other modules. This increases the dependencies between the modules (which may lead to ripple effects).
Furthermore adhering to this principle distributes responsibilities among several classes instead of having one central god object which uses other objects simply as dumb data containers.
Sometimes assigning responsibilities using IE results in bad solutions (high coupling, low cohesion). This is because IE just focuses on the availability of data. So for example IE would demand domain objects saving themselves to the database. This is bad since it couples the domain objects to the database interface (JDBC, SQL, etc.) and lowers cohesion by adding unrelated responsibilities to the classes. Here it is better to give the task of persisting the domain objects to a separate class.4)
See also section contrary principles.
Craig Larman: Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development
Accepted: This principle is prominently described in Craig Larman's book Applying UML and Patterns.
Discuss this wiki article and the principle on the corresponding talk page.