principles:principle_of_separate_understandability
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:principle_of_separate_understandability [2013-10-07 11:46] – referenced refactorings in strategies christian | principles:principle_of_separate_understandability [2013-10-07 14:26] – several minor improvements christian | ||
---|---|---|---|
Line 11: | Line 11: | ||
===== Principle Statement ===== | ===== Principle Statement ===== | ||
- | Each module shall be understandable on its own -- without knowing anything about other modules. | + | Each module shall be understandable on its own---without knowing anything about other modules. |
Line 20: | Line 20: | ||
* By looking at the public methods of a class it should be clear why they are there. That means there should be no method that is only there because a specific other module needs it. | * By looking at the public methods of a class it should be clear why they are there. That means there should be no method that is only there because a specific other module needs it. | ||
* By looking at the implementation of a module it should be clear how it works and why it was done that way. That means there should be no code that is solely there in order to make another module work. | * By looking at the implementation of a module it should be clear how it works and why it was done that way. That means there should be no code that is solely there in order to make another module work. | ||
- | * By looking at a private method it should be clear what it does. That means there should be no (private) method that is only meaningful in the context of another method. | + | * By looking at a private method it should be clear what it does. That means there should be no (private) method that is only meaningful in the context of another method |
- | * By looking at a method invocation it should be clear what happens, why the parameters are there, and what they specify. It should not be necessary to look up the method implementation. | + | * By looking at a method invocation it should be clear what happens, why the parameters are there, and what they specify. It should not be necessary to look up the method implementation |
* By looking at a single line of code it should be clear what it does without having to look up other code. | * By looking at a single line of code it should be clear what it does without having to look up other code. | ||
Line 42: | Line 42: | ||
===== Strategies ===== | ===== Strategies ===== | ||
- | When a module does not comply with PSU, this means that either a part of the functionality of the module does not belong here or the module has the wrong abstraction. So strategies for making a solution more compliant with PSU are: | + | When a module does not comply with PSU, this means that either a part of the functionality of the module does not belong here (see [[#Example 1: Parsing Data|example 1]]) or the module has the wrong abstraction |
* Move the conflicting functionality to another module where it fits better: [[refactorings: | * Move the conflicting functionality to another module where it fits better: [[refactorings: | ||
Line 141: | Line 141: | ||
* First version: see ((http:// | * First version: see ((http:// | ||
* Second version: see ((http:// | * Second version: see ((http:// | ||
+ | |||
+ | |||
+ | ==== Example 3: Unnecessary State and Wrong Abstractions ==== | ||
+ | |||
+ | This example is also inspired by Robert C. Martin. Have a look at the following piece of code from [[resources: | ||
+ | <code java> | ||
+ | public String make(char candidate, int count) | ||
+ | { | ||
+ | createPluralDependentMessageParts(count); | ||
+ | return String.format(" | ||
+ | } | ||
+ | </ | ||
+ | What does it do? Certainly some information is missing to answer this question. This piece of code is not separately understandable. You might feel the urge to ask for the implementation of '' | ||
+ | |||
+ | <code java> | ||
+ | private void createPluralDependentMessageParts(int count) | ||
+ | { | ||
+ | if (count == 0) | ||
+ | { | ||
+ | thereAreNoLetters(); | ||
+ | } | ||
+ | else if (count == 1) | ||
+ | { | ||
+ | thereIsOneLetter(); | ||
+ | } | ||
+ | else | ||
+ | { | ||
+ | thereAreManyLetters(count); | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | Again, you most likely won't be satisfied and ask for the rest of the implementation: | ||
+ | |||
+ | <code java> | ||
+ | public class Statistics2 | ||
+ | { | ||
+ | | ||
+ | { | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | } | ||
+ | |||
+ | | ||
+ | { | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | { | ||
+ | | ||
+ | | ||
+ | } | ||
+ | |||
+ | | ||
+ | { | ||
+ | if (count == 0) | ||
+ | { | ||
+ | | ||
+ | } | ||
+ | else if (count == 1) | ||
+ | { | ||
+ | | ||
+ | } | ||
+ | else | ||
+ | { | ||
+ | | ||
+ | } | ||
+ | } | ||
+ | |||
+ | | ||
+ | { | ||
+ | | ||
+ | verb = " | ||
+ | | ||
+ | } | ||
+ | |||
+ | | ||
+ | { | ||
+ | | ||
+ | verb = " | ||
+ | | ||
+ | } | ||
+ | |||
+ | | ||
+ | { | ||
+ | | ||
+ | verb = " | ||
+ | | ||
+ | } | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | Only if you read all that code, you really get what's going on. Also if you started with some other method, you would not understand it. It's clear what '' | ||
+ | |||
+ | The problem cannot be solved by moving or renaming methods or fields. The abstraction of the methods is wrong. The methods are just groupings of code and have no distinct meaning. The uncommon naming scheme of the methods lacking an imperative form of a verb might be an indicator for that. | ||
+ | |||
+ | The functionality is buried in the class which is most obvious with the '' | ||
+ | |||
+ | A better solution might be the following: | ||
+ | |||
+ | <code java> | ||
+ | public class Statistics3 | ||
+ | { | ||
+ | enum Number {SINGULAR, PLURAL} | ||
+ | |||
+ | | ||
+ | { | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | } | ||
+ | |||
+ | | ||
+ | { | ||
+ | | ||
+ | | ||
+ | | ||
+ | } | ||
+ | |||
+ | | ||
+ | { | ||
+ | | ||
+ | } | ||
+ | |||
+ | | ||
+ | { | ||
+ | | ||
+ | } | ||
+ | |||
+ | | ||
+ | { | ||
+ | | ||
+ | } | ||
+ | |||
+ | | ||
+ | { | ||
+ | | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | Here virtually every piece of code is understandable on its own. | ||
===== Description Status ===== | ===== Description Status ===== | ||
Line 149: | Line 297: | ||
===== Further Reading ===== | ===== Further Reading ===== | ||
+ | |||
+ | * [[http:// | ||
===== Discussion ===== | ===== Discussion ===== | ||
Discuss this wiki article and the principle on the corresponding [[talk: | Discuss this wiki article and the principle on the corresponding [[talk: |
principles/principle_of_separate_understandability.txt · Last modified: 2021-10-18 22:13 by christian