Differences

This shows you the differences between two versions of the page.

--- principles:principle_of_separate_understandability [2013-08-10 10:59] – [Context] christian
+++ principles:principle_of_separate_understandability [2013-10-07 11:46] – referenced refactorings in strategies christian
@@ Line 28: / Line 28: @@
 When a module is separately understandable, it is easier to maintain, as no other modules have to be considered during maintenance. It is furthermore more testable, as a unit test can easily test only this particular module without requiring integration with other modules.
-Another point of view is that a violation of PSU either means that a part of the functionality does not belong to that module or the module has the wrong abstraction. So this is a sign of a design that needs improvement.
+An important  aspect of PSU is readability or rather understandability. If a module---say a method---requires to understand several other modules (other methods, the usage of certain attributes, the idea of the whole class, ...), a much larger part of the code has to be read and kept in memory. And if a method call is not separately understandable, the reader of the code will have to jump to the implementation of the method in order to see what's going on. This is unnecessarily time consuming:
+  * You have to find the implementation and jump there (modern IDEs help here but it takes time nevertheless)
+  * While doing so, you have to memorize the call and the context of the call. If implementation and call are not colocated (which is preferable but not always possible) you won't see the call anymore so you have to memorize it.
+  * Then you have to read the code and mentally inline it.
+  * If you could not memoroze everything, you might have to jump back and forth to do the job.
+  * After you did all that you have to jump back and continue reading the method with the call you just mentally inlined.
+In a nutshell, if you have to mentally inline code, it would have been better if it was already inlined. The [[refactorings:extract method|method extraction]] in fact was harmful to readability and not beneficial. Note that not extracting a method needn't be the best solution to the problem. Often renaming the extracted method already does the job. Maybe this also hints that not the right piece of code has been extracted.
+Another point of view is that a violation of PSU either means that a part of the functionality does not belong to that module or the module has the wrong abstraction. So this is a sign of a design that needs improvement.
 ===== Strategies =====
@@ Line 35: / Line 44: @@
 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:
-  * Move the conflicting functionality to another module where it fits better (see [[Tell don't Ask/Information Expert|IE]], [[High Cohesion|HC]], and [[Model Principle|MP]]).
+  * Move the conflicting functionality to another module where it fits better: [[refactorings:Move Field]], [[refactorings:Move Method]] (see [[Tell don't Ask/Information Expert|IE]], [[High Cohesion|HC]], and [[Model Principle|MP]]).
-  * Build up a new module for the conflicting functionality (see [[High Cohesion|HC]]).
+  * Build up a new module for the conflicting functionality: [[refactorings:Extract Method]], [[refactorings:Extract Class]] (see [[High Cohesion|HC]]).
   * Find the right abstraction for the module that allows the functionality to stay here (see [[Model Principle|MP]]).
+  * Find a name which properly describes the abstraction of the module: [[refactorings:Rename Module]] ([[Model Principle|MP]]).
 ===== Caveats =====