principles:rule_of_explicitness
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:rule_of_explicitness [2013-03-03 11:02] – relations, strategies christian | principles:rule_of_explicitness [2021-10-14 21:54] – old revision restored (2021-09-02 12:38) 46.161.27.210 | ||
---|---|---|---|
Line 7: | Line 7: | ||
===== Context ===== | ===== Context ===== | ||
/* fill in contexts here: */ | /* fill in contexts here: */ | ||
- | * [[contexts: | + | * [[contexts: |
+ | * [[contexts: | ||
Line 17: | Line 18: | ||
===== Description ===== | ===== Description ===== | ||
+ | Solutions often differ in the level of explicitness. A feature can be implemented explicitly or it can be a side-effect of the implementation of another feature or a more general functionality. The same applies to module communication. A module can invoke another module directly or there can be various forms of indirections like events or observers. | ||
+ | RoE states that explicit solutions are better than implicit ones. Indirection, | ||
===== Rationale ===== | ===== Rationale ===== | ||
+ | If something is realized explicitly, it is easier to understand. Implicit solutions require the developer to have a deeper understanding of the module as it is necessary to "read between the lines" | ||
===== Strategies ===== | ===== Strategies ===== | ||
Line 35: | Line 39: | ||
* In Python and other languages that allow this use named parameters. | * In Python and other languages that allow this use named parameters. | ||
* Avoid long parameter lists and use objects with explicit attribute assignments instead. (see [[Option-Operand Separation]]) | * Avoid long parameter lists and use objects with explicit attribute assignments instead. (see [[Option-Operand Separation]]) | ||
+ | * Use parameter types that explicitly state what the input is. Rather use specific types for parameters like customers, articles, URLs, colors, money, etc. instead of using strings or integers for these values (see [[anti-patterns: | ||
* Avoid implicit type conversions. | * Avoid implicit type conversions. | ||
* In C# do not to specify implicit cast operations | * In C# do not to specify implicit cast operations | ||
Line 79: | Line 84: | ||
* [[Generalization Principle]] (GP): RoE often results in specific solutions. Generality often requires stating something implicitly. | * [[Generalization Principle]] (GP): RoE often results in specific solutions. Generality often requires stating something implicitly. | ||
* [[Low Coupling]] (LC): Direct communication typically has the disadvantage of a higher coupling. Indirection reduces coupling but creates implicit/ | * [[Low Coupling]] (LC): Direct communication typically has the disadvantage of a higher coupling. Indirection reduces coupling but creates implicit/ | ||
+ | |||
==== Complementary Principles ==== | ==== Complementary Principles ==== | ||
Line 84: | Line 90: | ||
* [[Keep It Simple Stupid]] (KISS): Explicit solutions are often also simpler. | * [[Keep It Simple Stupid]] (KISS): Explicit solutions are often also simpler. | ||
* [[Murphy' | * [[Murphy' | ||
+ | * [[Model Principle]] (MP): RoE states that [[anti-patterns: | ||
+ | |||
==== Principle Collections ==== | ==== Principle Collections ==== | ||
Line 90: | Line 98: | ||
- | ===== Example | + | ===== Examples |
principles/rule_of_explicitness.txt · Last modified: 2021-10-18 22:06 by christian