principles:more_is_more_complex
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
principles:more_is_more_complex [2021-09-02 10:44] – old revision restored (2021-05-19 09:40) 65.21.179.175 | principles:more_is_more_complex [2021-09-02 17:57] – old revision restored (2021-05-19 09:40) 65.21.179.175 | ||
---|---|---|---|
Line 6: | Line 6: | ||
===== Context ===== | ===== Context ===== | ||
/* fill in contexts here: */ | /* fill in contexts here: */ | ||
- | * [[contexts: | + | * [[contexts: |
+ | * [[contexts: | ||
+ | * [[contexts: | ||
+ | * [[contexts: | ||
+ | * [[contexts: | ||
===== Principle Statement ===== | ===== Principle Statement ===== | ||
Line 17: | Line 20: | ||
Having more lines of code, methods, classes, packages, executables, | Having more lines of code, methods, classes, packages, executables, | ||
+ | |||
+ | There is both: too large modules (i.e. undermodularization) and too small modules (i.e. overmodularization). Either there is too much complexity in a module (MIMC applied to one module) or there is too much complexity between the modules (MIMC applied to the number of modules). | ||
Note that it is actually not the number of lines, methods, classes, etc. that is relevant but the effective number of items that have to be kept in mind for the purpose of understanding. So reducing the number of lines by placing several statements in one line does not help. Neither the introduction of an additional obvious private method exceeding the limit will do any harm. MIMC is just a rule of thumb stating that the introduction of further modules (and the like) usually has a higher complexity as a drawback. | Note that it is actually not the number of lines, methods, classes, etc. that is relevant but the effective number of items that have to be kept in mind for the purpose of understanding. So reducing the number of lines by placing several statements in one line does not help. Neither the introduction of an additional obvious private method exceeding the limit will do any harm. MIMC is just a rule of thumb stating that the introduction of further modules (and the like) usually has a higher complexity as a drawback. | ||
Line 32: | Line 37: | ||
* Don't introduce a new module but put the functionality into another module | * Don't introduce a new module but put the functionality into another module | ||
* Avoid big modules | * Avoid big modules | ||
- | * Divide large modules | + | * Divide large modules |
+ | * Introduce new modules to group related functionality. A [[patterns: | ||
===== Caveats ===== | ===== Caveats ===== | ||
Line 46: | Line 51: | ||
===== Origin ===== | ===== Origin ===== | ||
- | The phrase "more is more complex" | + | The phrase "more is more complex" |
===== Evidence ===== | ===== Evidence ===== | ||
/* Comment out what is not applicable and explain the rest: */ | /* Comment out what is not applicable and explain the rest: */ | ||
- | * [[wiki: | + | /* * [[wiki:Proposed]]*/ |
- | + | ||
- | /* * [[wiki:Examined]]*/ | + | |
/* * [[wiki: | /* * [[wiki: | ||
- | /* * [[wiki: | ||
+ | [[wiki: | ||
+ | |||
+ | This phenomenon that the defect density is high for small modules but also rises for large modules is called the " | ||
+ | |||
+ | This sounds intuitive but the Goldilocks Conjecture is disputed. Some point out that the negative correlation between defect density and size is just a mathematical artifact((Jarrett Rosenberg: //Some Misconceptions About Lines of Code// | ||
+ | |||
+ | The relationship between module size and defect proneness is complex and not clear. Furthermore modularization is not only a task in terms of module size. The more interesting aspect is how to assign responsibilities to modules. So apart from module size there are many other aspects influencing modularization (see especially [[Model Principle|MP]], | ||
+ | |||
+ | This is an important research question but as MIMC is just a qualitative rule of thumb (just as the other principles are). So the principle can be deemed helpful despite the Goldilocks Conjecture being disputed. | ||
+ | |||
+ | As a specific aspect of MIMC, complexity through deep inheritance relations is known to reduce effectiveness and efficiency of maintenance. There are controlled experiments showing this((John Daly, Andrew Brooks, James Miller, Marc Roper and Murray Wood: //An Empirical Study Evaluating Depth of Inheritance on the Maintainability of Object-Oriented Software// | ||
+ | |||
+ | [[wiki: | ||
===== Relations to Other Principles ===== | ===== Relations to Other Principles ===== | ||
Line 83: | Line 98: | ||
- | ===== Example | + | ===== Examples |
FIXME | FIXME | ||
Line 96: | Line 111: | ||
===== Further Reading ===== | ===== Further Reading ===== | ||
+ | ===== Discussion ===== | ||
+ | Discuss this wiki article and the principle on the corresponding [[talk: |
principles/more_is_more_complex.txt · Last modified: 2021-10-20 21:26 by christian