about:characterizing_sets_and_weighting_principles
no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
— | about:characterizing_sets_and_weighting_principles [2013-09-12 17:51] (current) – created christian | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Characterizing Sets And Weighting Principles ====== | ||
+ | ===== 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: |
about/characterizing_sets_and_weighting_principles.txt · Last modified: 2013-09-12 17:51 by christian