This is an old revision of the document!
Each principle may have several alternative names. This may be because the same principle has been described several times independently. A principle may also evolve over time, change its name, change its meaning, may be applied to other contexts, etc. So there may be several names referring basically to the same principle. This also means that the alternative names may roughly correspond to certain views on the principle. The views may differ slightly resulting in certain variations of the principle. Alternative names are listed in this section and, if necessary, explained. The views may differ slightly resulting in certain variations of the principle.
Alternative names are listed in this section and, if necessary, explained. Variations are also explained and, depending on the difference, may additionally be described on a separate wiki page.
Principles apply in certain contexts. A context is a basic category for principles like OOD, web development, framework development, user interface design, etc. It describes during which task the principle can be considered. A principle has at least one context but also may have several contexts.
The principle statement is basically a concise explanation in one or two sentences. This may be the original wording or a new one. The main purpose is to give a memorable “definition” of the principle.
As one or two sentences are never enough to explain a principle in detail, there is a separate section describing what the principle means and how it is applied.
Principles normally are not hard rules but rather heuristics or rules of thumb. So there is no formal proof showing that the principle is correct in each and every situation. Nevertheless there needs to be a reason for the principle, meaning some rationale explaining why it is valid. In order to assess whether the principle is applicable to a certain problem, the rationale can be used. If the reasons given in this section apply to the given problem, the principle can be applied.
The main idea behind principles is to assess solutions and not to construct solutions. Nevertheless applying principles may lead to the conclusion that a solution is not as good as it could be. This section lists strategies that can be used to transform a given solution in a way that the result better adheres to the principle. So the principle language provides guidance beyond the pure assessment of design solutions. A generative approach for constructing solutions is nevertheless necessary.
This section lists warnings on how not to use this principle. Disadvantages are partly treated below in the section “contrary principles”. Nevertheless there are sometimes helpful remarks on pitfalls and wrong usages that cannot be described using contrary principles or that are otherwise noteworthy. This section discusses these issues.
This section describes where the principle comes from, where it has been prominently described, etc.
Apart from the rationale there may be different evidence that the principle holds:
There are certain relationships among principles. This section lists and explains them so the consideration of one principle inevitably leads to other principles that can be considered. An important aspect of this is that the pure purpose of this list of relationships is to give a clear navigation path to the principles that should be considered next. These relationships are fuzzy and sometimes not valid in every respect. But this is not a problem since their purpose is to be practically useful. A purely “academic” analysis of the principles which ignores their practical usage is not intended.
A generalization of a principle is another principle that can be applied in a broader context or one that is less demanding. Generalizations may be considered in addition or instead of the principle. If a principle does not fit well to the problem, a generalization of it may fit better. It may also add further reasons and a broader view for the assessment of possible solutions.
The principle is always a specialization of its generalizations. There may also be several generalizations, for example when a principle is a consequence of two others.
A specialization is a more concrete principle that either applies in a narrower context, makes more prescriptions, or is some kind of corollary. Specializations may be considered in addition or instead of the principle. If a principle does not fit well to the problem, a specialization of it may fit better. It may be easier to apply and more tailored to specific kinds of problems.
The principle is always a generalization of its specializations and naturally there may be several specializations.
Following the principle may have a negative impact on aspects addressed by other principles. These contrary principles are listed here and the consequence is explained. Like there is no guarantee that the principle itself is valid in every case, there is also no guarantee that there is the negative effect concerning the other principles. There is just a high probability that there is this effect. Therefore these principles should also be considered if this one is applied.
As the relationships are purely for navigational purposes, the ``is-contrary-to
relationship is not necessarily symmetric.
==== Complementary Principles ====
A principle is always a reduction of the given design problem to a very specific aspect or effect. Other principles have to be considered too in order to have a full picture of the design problem. Sometimes when one principle is considered, another one is very likely to be relevant too despite not being contrary. This is then a complementary principle. As for the other relations this is just a tendency and a purely navigational relationship. In practice a complementary principle may also be contrary or not applicable.
Similar to ``is-contrary-to``, the ``is-complementary-to relationship is not necessarily symmetric.
One or more self-contained examples explains how the principle distinguishes ``good
and ``bad solutions with respect to the aspect the principle is about or exemplifies certain relationships, strategies, caveats, etc.
As the wiki page evolves, it gets better and better. This section roughly states how complete it already is:
Apart from the original source which may be already mentioned in the origin section there may be other articles, discussions and wikis discussing the principle. If they are worth looking into, they are listed here.