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 [2013-09-06 15:10] – [Description] TdA == IE christianprinciples:tell_don_t_ask_information_expert [2015-06-29 12:02] – [Rationale] 2001:8d8:1ff:f850:579:faa2:b385:9e45
Line 41: Line 41:
 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]]).
  
 +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 =====
  
Line 49: Line 49:
 ===== Caveats ===== ===== Caveats =====
  
-Sometimes assigning responsibilities using IE results in bas 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))+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]]. See also section [[#contrary principles]].
principles/tell_don_t_ask_information_expert.txt · Last modified: 2021-10-18 21:42 by christian