User Tools

Site Tools


principles:tell_don_t_ask_information_expert

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
principles:tell_don_t_ask_information_expert [2013-02-11 18:59] – +IH/E christianprinciples:tell_don_t_ask_information_expert [2021-10-18 21:42] (current) – +++ restored +++ christian
Line 3: Line 3:
 ===== Variants and Alternative Names ===== ===== Variants and Alternative Names =====
  
-  * Expert +  * Information Expert or Expert in ((Craig Larman: //Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development//)) 
-  * Do It Myself+  * Do It Myself in ((Peter Coad: //Object Models: Strategies, Patterns and Applications// -- as stated in Craig Larman: //Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development//, p. 297)) 
 +  * Tell, don't Ask in ((Andrew Hunt and David Thomas: //[[http://www.ccs.neu.edu/research/demeter/related-work/pragmatic-programmer/jan_03_enbug.pdf|The Art of Enbugging]]// -- probably not the original source of this wording(?) ))
  
  
Line 10: Line 11:
 /* fill in contexts here: */ /* fill in contexts here: */
   * [[contexts:Object-Oriented Design]]    * [[contexts:Object-Oriented Design]] 
 +  * [[contexts:Implementation]]
  
 ===== Principle Statement ===== ===== Principle Statement =====
  
-Assign a responsibility to this [[glossary:module]] which has the largest subset of the required information. +  * Assign a responsibility to that [[glossary:module]] which has the largest subset of the required information. 
 +  * Don't ask an object for information, make computations and set values on the object later. Tell the object what it should do.
  
 ===== Description ===== ===== Description =====
  
-Each module has a set of responsibilities. Subsystems have specific tasks, packages group several related classes, classes have methods and attributes, and so on. So there is a kind of mapping between modules and responsibilities. This mapping is good when the information which is necessary to fulfill the given task is present in the given module so there is no need to acquire all this information.+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!".
  
-===== Rationale =====+The following reasoning shows that //Tell don't Ask// and //Information Expert// are essentially 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 modulesThis increases the dependencies between the modules (which may lead to[[glossary:ripple effects]]).+  * Suppose TdA is adhered to, but IE is neglected. 
 +    * When IE is neglected, then there is a module which is not the information expert for its responsibility. 
 +    * But then the module has to ask for the information it needs, so TdA is also neglected. 
 +    * As this violates the assumption that TdA is adhered to, this means that adhering to TdA also results in adhering to IE. 
 +  * Suppose IE is adhered to but TdA is neglected 
 +    * When TdA is neglected, then there is a module ''A'' which gets data from another module ''B'' and makes some computations or decisions which normally ''B'' could do. 
 +    * But then ''B'' is the information expert and not ''A'', so IE is neglected. 
 +    * As this violates the assumption that IE is adhered to, this means that adhering to IE also results in adhering to TdA. 
 +  * So TdA and IE are equivalent views on the same principle. 
 + 
 +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. 
 +===== Rationale =====
  
 +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 [[glossary:ripple effects]]).
  
 +Furthermore adhering to this principle distributes responsibilities among several classes instead of having one central [[anti-patterns:god object]] which uses other objects simply as dumb data containers.
 ===== Strategies ===== ===== Strategies =====
 +
 +  * Assign a responsibility to the class that has the largest subset of the needed information.
 +  * Mirror functionality of composed objects to the interface of the class instead of having a getter-method returning the composed object
 +  * Have the objects operate on their own data using appropriate methods. Avoid getters and setters.
 +===== Caveats =====
 +
 +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.((see Craig Larman: //Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development//, p. 298))
 +
 +See also section [[#contrary principles]].
  
  
Line 37: Line 61:
 ===== Evidence ===== ===== Evidence =====
 /* Comment out what is not applicable and explain the rest: */ /* Comment out what is not applicable and explain the rest: */
-/* + 
-  * [[wiki:Proposed]] +/*  * [[wiki:Proposed]]*/ 
-  * [[wiki:Examined]] +/*  * [[wiki:Examined]]*
-  * [[wiki:Accepted]] + 
-  * [[wiki:Questioned]] +[[wiki:Accepted]]: This principle is prominently described in Craig Larman's book //Applying UML and Patterns//. 
-*/+ 
 +/*  * [[wiki:Questioned]]*/ 
  
 ===== Relations to Other Principles ===== ===== Relations to Other Principles =====
  
 ==== Generalizations ==== ==== Generalizations ====
- 
-  * [[Low Coupling]] Adhering to the information expert principle leads to low coupling as there is less need to communicate with other modules to get the necessary information. 
-  * [[High Cohesion]] Adhering to information expert also means that a module only has responsibilities which belong together. So this increases cohesion. 
  
 ==== Specializations ==== ==== Specializations ====
Line 56: Line 79:
  
   * [[More Is More Complex]] (MIMC): Adhering to TdA/IE sometimes results in adding further methods.   * [[More Is More Complex]] (MIMC): Adhering to TdA/IE sometimes results in adding further methods.
-  * [[Principle of Separate Understandability]] (PSU): Assigning responsibilities using TdA/IE bears the danger of violating PSU as responsibilities are assigned based on data availability instead of separate understandability. 
  
 ==== Complementary Principles ==== ==== Complementary Principles ====
  
 +  * [[Low Coupling]] Adhering to IE typically leads to low coupling as there is less need to communicate with other modules to get the necessary information. But in some cases IE also increases coupling (see [[#caveats]]. 
 +  * [[High Cohesion]] Adhering to IE typically leads to high cohesion as responsibilities which belong together typically operate on the same data. But in some cases IE also lowers cohesion (see [[#caveats]]). 
   * [[Model Principle]] (MP): TdA/IE tells how to distribute functionality among the natural classes which are created according to the Model Principle.   * [[Model Principle]] (MP): TdA/IE tells how to distribute functionality among the natural classes which are created according to the Model Principle.
-  * [[Information Hiding/Encapsulation]] (IH/E): Assigning responsibilities to objects using Information Expert may accidentally break encapsulation. It typically does not but it has to be considered.+  * [[Information Hiding/Encapsulation]] (IH/E): Assigning responsibilities to objects using Information Expert may accidentally break encapsulation. It typically does not but it has to be considered. Furthermore TdA is about not having getter methods returning constituent parts of a module. Encapsulation can be another reason for that. 
 +  * [[Principle of Separate Understandability]] (PSU): TdA/IE is about responsibility assignment. Another aspect of this task is treated by PSU.
  
 ==== Principle Collections ==== ==== Principle Collections ====
Line 69: Line 94:
  
  
-===== Example =====+===== Examples =====
  
  
 ===== Description Status ===== ===== Description Status =====
 /* Choose one of the following and comment out the rest: */ /* Choose one of the following and comment out the rest: */
-[[wiki:Stub]] +/*[[wiki:Stub]]*
-/*[[wiki:Incomplete]]*/+[[wiki:Incomplete]]
 /*[[wiki:Complete]]*/ /*[[wiki:Complete]]*/
  
Line 83: Line 108:
   * [[wp>GRASP_(object-oriented_design)#Information_Expert]]   * [[wp>GRASP_(object-oriented_design)#Information_Expert]]
   * Andrew Hunt and David Thomas: //[[http://www.ccs.neu.edu/research/demeter/related-work/pragmatic-programmer/jan_03_enbug.pdf|The Art of Enbugging]]//   * Andrew Hunt and David Thomas: //[[http://www.ccs.neu.edu/research/demeter/related-work/pragmatic-programmer/jan_03_enbug.pdf|The Art of Enbugging]]//
 +
 +===== Discussion =====
 +
 +Discuss this wiki article and the principle on the corresponding [[talk:principles:Tell Don't Ask/Information Expert|talk page]].
  
principles/tell_don_t_ask_information_expert.1360605550.txt.gz · Last modified: 2013-05-19 22:10 (external edit)