principles:rule_of_explicitness
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revisionNext revisionBoth sides next revision | ||
principles:rule_of_explicitness [2013-02-28 22:43] – created christian | principles:rule_of_explicitness [2021-09-02 12:38] – old revision restored (2021-05-11 22:22) 65.21.179.175 | ||
---|---|---|---|
Line 7: | Line 7: | ||
===== Context ===== | ===== Context ===== | ||
/* fill in contexts here: */ | /* fill in contexts here: */ | ||
- | * [[contexts: | + | * [[contexts: |
+ | * [[contexts: | ||
Line 22: | Line 23: | ||
===== Strategies ===== | ===== Strategies ===== | ||
+ | |||
+ | * Avoid indirection (but keep [[Low Coupling|LC]] in mind) | ||
+ | * Avoid indirection though events/ | ||
+ | * Avoid indirecting middleware like messaging middleware in favor of direct communication. Explicit communication paths are easier to grasp and debug. | ||
+ | * Avoid configurability (but keep [[Generalization Principle|GP]] in mind) | ||
+ | * Avoid using configuration files for specifying behavior. Instead implement varying behavior explicitly. | ||
+ | * Avoid highly configurable modules. Instead implement varying behavior explicitly. | ||
+ | * Explicitly state which module to use | ||
+ | * Avoid importing all classes of a given package/ | ||
+ | * Avoid '' | ||
+ | * Explicitly name 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]]) | ||
+ | * 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. | ||
+ | * In C# do not to specify implicit cast operations | ||
+ | * In C++ use the '' | ||
+ | * In PHP use the '' | ||
Line 61: | Line 80: | ||
* [[More Is More Complex]] (MIMC): Stating something explicitly requires more code. | * [[More Is More Complex]] (MIMC): Stating something explicitly requires more code. | ||
* [[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/ | ||
+ | |||
==== Complementary Principles ==== | ==== Complementary Principles ==== | ||
* [[Keep It Simple Stupid]] (KISS): Explicit solutions are often also simpler. | * [[Keep It Simple Stupid]] (KISS): Explicit solutions are often also simpler. | ||
+ | * [[Murphy' | ||
+ | * [[Model Principle]] (MP): RoE states that [[anti-patterns: | ||
+ | |||
==== Principle Collections ==== | ==== Principle Collections ==== | ||
+ | |||
+ | {{page> | ||
- | ===== Example | + | ===== Examples |
principles/rule_of_explicitness.txt · Last modified: 2021-10-18 22:06 by christian