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
Next revisionBoth sides next revision
principles:tell_don_t_ask_information_expert [2020-10-12 16:39] – old revision restored (2013-08-10 10:56) 159.69.186.191principles:tell_don_t_ask_information_expert [2021-09-02 12:51] – old revision restored (2021-05-11 22:31) 65.21.179.175
Line 11: 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 that [[glossary:module]] which has the largest subset of the required information. +Assign a responsibility to this [[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 =====
Line 25: Line 25:
 ===== Rationale ===== ===== 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]]).+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]]).
  
  
 ===== 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 ===== ===== Caveats =====
  
Line 47: Line 45:
 ===== 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:Accepted]]: This principle is prominently described in Craig Larman's book //Applying UMl and Patterns//. +  * [[wiki:Questioned]] 
- +*/
-/*  * [[wiki:Questioned]]*/ +
  
 ===== Relations to Other Principles ===== ===== Relations to Other Principles =====
Line 69: Line 65:
  
   * [[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]].    * [[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]])+  * [[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. Furthermore TdA is about not having getter methods returning constituent parts of a module. Encapsulation can be another reason for that.   * [[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 80: Line 75:
  
  
-===== Examples =====+===== Example =====
  
  
 ===== 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 95: Line 90:
   * 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.txt · Last modified: 2021-10-18 21:42 by christian