User Tools

Site Tools


Frequently Asked Questions

Q: How to use the principles in order to design software?
A: Normally you don't. The purpose of principles and principle languages is to assess designs, not to generate them. It's an analytical approach rather than a generative one. Nevertheless the wiki gives small hints. For each principle there is a “strategies” section which describes refactorings, patterns, and hints which might be applied in order to improve a design wrt. certain principles. This is not a replacement for a complete generative design approach but helps improving existing designs. See Generative vs. Analytic Design Approaches.
Q: Have you ever checked if the OOD Principle Language is consistent?
A: The relationships between the principles are not of a kind where a consistency check can be applied. The relationships are designed for being helpful for designers. They do not reflect any mathematically clear relationship between the principles which could be objectively checked. For example there is the “is-contrary-to” relationship. One might think that a consistency check could verify that there are no circles in this relationship. But that's not the case. In fact there is even a principle which is contrary to itself (MIMC). This is is not a problem since is-contrary-to does not mean, there is a logical contradiction between the principles. It just says “If you consider principle A, have a look at principle B as it might point to some disadvantage/contrary aspect (but this needn't be the case).”. The only meaningful consistency rule would be to check that there are no cycles in generalization relationships.
Q: Why is LC contrary to HC? It rather seems complementary.
A: This depends on the design decision which should be taken. Suppose you have the task of modularizing a software into classes. There is a certain amount of essential complexity which needs to go somewhere. Either complexity is in the classes (leading to few, complex, less cohesive but loosely coupled modules). Or complexity is between the classes (leading to many, simple, cohesive modules with more complex couplings). The extreme cases would be to have one single module (extremely low cohesion and no coupling at all) or hundreds of tiny modules communicating with many others (very cohesive but strongly coupled). Here you can see the contrary nature of the relationship. Another contrary aspect is that the cohesion of classes directly corresponds with the internal coupling of its methods. Of course there are plenty of situations where LC and HC are rather complementary. But the goal of the relationship is not to represent a hard and fast relationship but simply to be useful. Contrary relationships point to possible downsides and when coupling is considered, you should keep an eye on cohesion so it doesn't create a disadvantage and vice versa.
Q: Some relationships seem to be missing.
A: In this case there are two possibilities. Either a relationship is missing indeed. Then you may just add it. This wiki is still work in progress and will ever be. On the other hand there are relationships which are deliberately not there. It is important to understand that the documented relationships are not mathematically clear, academic relationships. Rather it a relationship expresses the fact that in a situation where principle A is considered, B might be worth considering, too. That means, the relationships “is-contrary-to” and “is-complementary-to” are not symmetric, although they sound like they should be so. For example considering KISS is very often a good idea and one would want to navigate to KISS from various other principles as it is contrary to very many of them. On the other hand one would not want to navigate to all the other principles KISS is contrary to, when considering KISS. So this relationship is not documented as it would be purely academic and not helpful at all.
about/frequently_asked_questions.txt · Last modified: 2013-12-09 14:30 by christian