User Tools

Site Tools


about:navigating_principle_languages

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
about:navigating_principle_languages [2013-09-14 18:05] christianabout:navigating_principle_languages [2013-09-16 17:27] (current) – decision christian
Line 38: Line 38:
 ==== Context ==== ==== Context ====
  
-The following example shows the usage of the OOD Principle Language. It details the assessment of a solution found in the CoCoME system((http://www.cocome.org/)). The details of the system are irrelevant here but it resembles an information system which can be found in supermarkets or other stores. There are several components which are grouped into the typical layers of an information system: The presentation layer (GUI), the application or business logic layer and the data layer.+The following---rather sophisticated---example shows the usage of the OOD Principle Language. It details the assessment of a solution found in the CoCoME system((http://www.cocome.org/)). The details of the system are irrelevant here but it resembles an information system which can be found in supermarkets or other stores. There are several components which are grouped into the typical layers of an information system: The presentation layer (GUI), the application or business logic layer and the data layer.
  
 In CoCoME there is a mechanism for getting access to other components. In a nutshell it works like this: In CoCoME there is a mechanism for getting access to other components. In a nutshell it works like this:
Line 93: Line 93:
 ==== Finding a Characterizing Set ==== ==== Finding a Characterizing Set ====
  
-{{ :collections:ood_principle_language.png?300 |}}+{{ :collections:ood_principle_language.png?400 |}}
  
 We will examine this question using the OOD principle language. First we have to find suitable starting principles. This is one of the rather sophisticated cases where finding a starting principle is at least not completely obvious. If we don't have a clue where to start, we'll have a look at the different categories of principles in the language. Essentially the "factory" enables modules to access and communicate with each other. So we are looking for principles about module communication. There are three of them in the principle language: [[principles:Tell, don't Ask/Information Expert|TdA/IE]], [[principles:Low Coupling|LC]], and [[principles:Dependency Inversion Principle|DIP]]. TdA/IE does not seem to fit, but LC seems to help. Coupling should be low and the mechanism couples modules in a certain way. So we'll choose LC as a starting principle and our characterizing set looks like this: {LC}. We will examine this question using the OOD principle language. First we have to find suitable starting principles. This is one of the rather sophisticated cases where finding a starting principle is at least not completely obvious. If we don't have a clue where to start, we'll have a look at the different categories of principles in the language. Essentially the "factory" enables modules to access and communicate with each other. So we are looking for principles about module communication. There are three of them in the principle language: [[principles:Tell, don't Ask/Information Expert|TdA/IE]], [[principles:Low Coupling|LC]], and [[principles:Dependency Inversion Principle|DIP]]. TdA/IE does not seem to fit, but LC seems to help. Coupling should be low and the mechanism couples modules in a certain way. So we'll choose LC as a starting principle and our characterizing set looks like this: {LC}.
Line 182: Line 182:
     * The rating of RoE depends on the concrete variant of the pattern. In the DI approach the dependencies are explicitly visible on the interface, which is not the case in the two other approaches. In solution F the dependency is not visible from the interface at all. Same with SL if the service locator is globally accessible. Even if a reference to the service locator is explicitly passed around, it is still not visible which services provided by the locator are used. On the other hand getting a reference is explicit with F and SL. In the DI approach it is only explicit when it is done manually. Typical DI frameworks wire the instances implicitly.     * The rating of RoE depends on the concrete variant of the pattern. In the DI approach the dependencies are explicitly visible on the interface, which is not the case in the two other approaches. In solution F the dependency is not visible from the interface at all. Same with SL if the service locator is globally accessible. Even if a reference to the service locator is explicitly passed around, it is still not visible which services provided by the locator are used. On the other hand getting a reference is explicit with F and SL. In the DI approach it is only explicit when it is done manually. Typical DI frameworks wire the instances implicitly.
   * TdA/IE   * TdA/IE
-    * FIXME+    * DI > SL = F 
 +    * For SL and F one first has to ask for an instance for calling a method on it. In DI the instance is already known, i.e. set from the outside.
   * ML   * ML
 +    * F > DI > SL
 +    * In the DI solution a possible fault would be to have different modules reference different instances of the same class where they should rather reference the same instance. In SL solution there is even a more problematic fault which could be introduced. Eventually somebody might get the idea to change the registered instances in the locator at runtime. This would then be the source for some hard to find defects: Some modules will cache the instance they got from the service locator in an attribute and some won't. In such a case the latter will receive the new instance while the former won't.
 +
 +As you can see all three possibilities have their advantages and disadvantages. The designer now has to weight the aspects in order to get to a decision. In this case we might state the following:
 +
 +  * F is ruled out because it is not testable. The other two approaches have lower couplings (LC) which make them better testable. The advantages wrt. KISS and ML do not justify that liability.
 +  * The solutions DI and SL are not very far apart but DI is slightly better wrt. LC, TdA/IE and ML. 
 +  * TdA/IE can be regarded less important because it is a heuristic which is normally applied in other situations.
 +  * For RoE we also have to decide whether to use a framework or not. In CoCoME we would rather want to avoid a framework because the rest of the system is implemented in that way ([[principles:Uniformity Principle|UP]]). We could incorporate that aspect in the characterizing principle or make another decision based on a newly created one. If we are comfortable with making the decision without constructing a characterizing set, just based on UP, we could also do that. In order not to complicate the example and in order to show this possibility, we'll do the latter. So a framework won't be used and manual dependency injection is good wrt. RoE.
 +
 +Based on this weighting, we decide to use DI.
about/navigating_principle_languages.txt · Last modified: 2013-09-16 17:27 by christian