about:navigating_principle_languages
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
about:navigating_principle_languages [2013-09-12 17:12] – traversion the PL in the example christian | about:navigating_principle_languages [2013-09-14 15:55] – code DataImpl christian | ||
---|---|---|---|
Line 4: | Line 4: | ||
When making a design decision based on principles, it is necessary to find those principles which fit to the given design problem. This means the [[glossary: | When making a design decision based on principles, it is necessary to find those principles which fit to the given design problem. This means the [[glossary: | ||
- | |||
- | |||
- | ===== Characterizing Sets ===== | ||
- | |||
- | A principle language cannot free the designer from actually taking a decision. There is no algorithm which replaces a sound judgment. Rather principle languages point to the relevant aspects to consider. For a given design problem, the result is a characterizing set of principles which describes the dimensions of the design space, i.e. the advantages and disadvantages of possible solutions. A typical characterizing set has around five principles. | ||
- | |||
- | There are two typical questions which can be answered using a characterizing set: | ||
- | |||
- | - Given a design problem and a solution, is the solution good? | ||
- | - Given a design problem and several solutions which one is the best, i.e. the appropriate one? | ||
- | |||
- | In the first case the solution can be rated according to the principles in the characterizing set. If the benefits justify the liabilities, | ||
- | |||
- | For the second question all the solutions are rated. The solutions which are not pareto-optimal (see [[conflicting principles]]) are clearly bad solutions. The others are all " | ||
- | |||
- | ===== Weighting Principles ===== | ||
- | |||
- | Note that it's not the number of principles which is essential. Weighting the principles and taking the decision is still the task of the designer. Sometimes the weights may be derived from the requirements. Where this is not possible the weighting is an expression of the personal style of the designer, the team or the project. | ||
- | |||
- | The [[principles: | ||
- | |||
- | Certainly some people will rather favor KISS and others will prefer DRY. Some will say one duplication is tolerable and you should only refactor when there are three similar pieces of code (see [[principles: | ||
Line 57: | Line 35: | ||
===== Example ===== | ===== 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:// | The following example shows the usage of the OOD Principle Language. It details the assessment of a solution found in the CoCoME system((http:// | ||
Line 63: | Line 43: | ||
* For the data layer there is a data component, a class '' | * For the data layer there is a data component, a class '' | ||
- | FIXME code for Data class | + | <code java> |
+ | public | ||
+ | { | ||
+ | public EnterpriseQueryIf getEnterpriseQueryIf() | ||
+ | { | ||
+ | return new EnterpriseQueryImpl(); | ||
+ | } | ||
+ | |||
+ | public PersistenceIf getPersistenceManager() | ||
+ | { | ||
+ | return new PersistenceImpl(); | ||
+ | } | ||
+ | |||
+ | public StoreQueryIf getStoreQueryIf() | ||
+ | { | ||
+ | return new StoreQueryImpl(); | ||
+ | } | ||
+ | } | ||
+ | </ | ||
* There are " | * There are " | ||
Line 73: | Line 71: | ||
private static DataIf dataaccess = null; | private static DataIf dataaccess = null; | ||
- | private DataIfFactory () {} | + | private DataIfFactory() {} |
- | public static DataIf getInstance () | + | public static DataIf getInstance() |
{ | { | ||
if (dataaccess == null) | if (dataaccess == null) | ||
{ | { | ||
- | dataaccess = new DataImpl (); | + | dataaccess = new DataImpl(); |
} | } | ||
return dataaccess; | return dataaccess; | ||
Line 88: | Line 86: | ||
Essentially '' | Essentially '' | ||
[[factory: | [[factory: | ||
+ | |||
+ | ==== Question ==== | ||
//Is this a good solution?// | //Is this a good solution?// | ||
+ | |||
+ | ==== Finding a Characterizing Set ==== | ||
{{ : | {{ : | ||
Line 143: | Line 145: | ||
As a result we get {LC, KISS, RoE, TdA/IE, ML} as the characterizing set. | 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 | + | 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 " | ||
+ | * 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 '' | ||
+ | * 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, |
about/navigating_principle_languages.txt · Last modified: 2013-09-16 17:27 by christian