This is an old revision of the document!
|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.|
|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 High Cohesion? 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.|