principles:principle_of_separate_understandability
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | Next revisionBoth sides next revision | ||
| principles:principle_of_separate_understandability [2013-10-07 10:21] – [Rationale] christian | principles:principle_of_separate_understandability [2013-10-07 11:46] – referenced refactorings in strategies christian | ||
|---|---|---|---|
| Line 44: | 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: | 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/ | + | * Move the conflicting functionality to another module where it fits better: [[refactorings: |
| - | * Build up a new module for the conflicting functionality (see [[High Cohesion|HC]]). | + | * Build up a new module for the conflicting functionality: [[refactorings: |
| * Find the right abstraction for the module that allows the functionality to stay here (see [[Model Principle|MP]]). | * 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: | ||
| ===== Caveats ===== | ===== Caveats ===== | ||
principles/principle_of_separate_understandability.txt · Last modified: 2021-10-18 22:13 by christian