Differences

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

--- about:navigating_principle_languages [2013-09-12 17:51] – moved characterizing sets and weighting princiles to an own page christian
+++ about:navigating_principle_languages [2013-09-14 15:47] – judgment christian
@@ Line 35: / Line 35: @@
 ===== Example =====
+==== 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.
@@ Line 66: / Line 68: @@
 Essentially ''DataIfFactory'' resembles a mixture between the design patterns [[patterns:factory]] and
 [[factory:singleton]]. The latter one is important here. The purpose of a singleton is to make a single instance of a class globally accessible. Here ''DataImpl'' is not ensured to be only instantiated once as it still has a public constructor. Nevertheless the "factory" class makes it globally accessible. In every part of the software ''DataIfFactory.getInstance()'' can be used to get hold of the data component. And since DataIf makes the three subcomponents accessible, also these are accessible from everywhere. There is no need to pass a reference around.
+==== Question ====
 //Is this a good solution?//
+==== Finding a Characterizing Set ====
 {{ :collections:ood_principle_language.png?300 |}}
@@ Line 121: / Line 127: @@
 As a result we get {LC, KISS, RoE, TdA/IE, ML} as the characterizing set.
-Note that although in this example the principles are examined in a certain order. Nevertheless the method does not prescribe any.
+Note that although in this example the principles are examined in a certain order, the method does not prescribe any.
+==== Using the Characterizing Set ====
+In order to answer the above question, we have to informally rate the solution based on the principles of the characterizing set:
+  * LC
+    * The solution creates a relatively strong coupling to the concrete implementations of the components. If a class uses the "factory" and the components it gives access to, there is no way to have the class use other implementations of the components. There is no way to replace the implementations by a stub for testing purposes, there is no way to smoothly switch to another ''Data'' component possibly using another way of storing the data. Every change in the arrangement of the classes needs a change in the code. LC is rather against this solution.
+  * KISS
+    * The solution is pretty easy to implement. Furthermore it is easy to get access to an arbitrary component. So according to KISS this is a good solution.
+  * RoE
+    * Getting access to a component is implicit. There is no need to explicitly pass a reference around. There is not even the necessity to explicitly define an attribute for the dependent class. RoE tells, that the solution is bad.
+  * TdA/IE
+    * Getting access to a the ''Store'' subcomponent requires asking ''DataIfFactory'' for the ''Data'' component and asking that one for the store. There is no way to tell the "factory" to do something. TdA/IE is against the solution.
+  * ML
+    * There are no particular pitfalls with this solution. So ML has nothing against it.
+So LC, RoE and TdA/IE are against the solution, KISS thinks it's good and ML has nothing against it. As it is not the number of principles which is important, the designer still has to make a sound judgment based on these results. What is more important: Coupling, testability, and clarity or a simple and fast implementation. In this case we'd rather decide that the former are more important, so we should rather think about a better solution.