User Tools

Site Tools


principles:rule_of_explicitness

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
principles:rule_of_explicitness [2013-08-04 14:04]
christian [Complementary Principles]
principles:rule_of_explicitness [2019-07-26 11:08] (current)
82.165.232.20 [Contrary Principles]
Line 9: Line 9:
   * [[contexts:​Object-Oriented Design]]   * [[contexts:​Object-Oriented Design]]
   * [[contexts:​API Design]]   * [[contexts:​API Design]]
 +  * [[contexts:​Implementation]]
  
 ===== Principle Statement ===== ===== Principle Statement =====
Line 34: Line 34:
     * Avoid highly configurable modules. Instead implement varying behavior explicitly.     * Avoid highly configurable modules. Instead implement varying behavior explicitly.
   * Explicitly state which module to use   * Explicitly state which module to use
-    * Avoid importing all classes of a given package/​namespace and import the needed classes explicitly. In Java this means not to specify wildcard imports like ''​import package.*''​ and to avoid static imports. Similarly in Python this means not to use wildcard imports.+    * Avoid importing all classes of a given package/​namespace and import the needed classes explicitly. In Java this means not to specify wildcard imports like ''​import package.*''​ and to avoid static imports. Similarly in Python this means not to use wildcard imports. In C++, do not import entire namespaces (e.g. do not use ''​using namespace std;''​).
     * Avoid ''​with''​ statements in Delphi and other languages having constructs that let you invoke methods without explicitly stating the associated object.     * Avoid ''​with''​ statements in Delphi and other languages having constructs that let you invoke methods without explicitly stating the associated object.
   * Explicitly name parameters   * Explicitly name parameters
Line 84: 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/​indirect communication paths. ​   * [[Low Coupling]] (LC): Direct communication typically has the disadvantage of a higher coupling. Indirection reduces coupling but creates implicit/​indirect communication paths. ​
- +  * [[Don'​t Repeat Yourself]] (DRY): Following RoE sometimes leads to duplication.
 ==== 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'​s Law]] (ML):The typical reason for RoE is to avoid unnecessarily complicated solutions and possibilities for defects. Don'​t ​loose that goal out of sight.+  * [[Murphy'​s Law]] (ML):The typical reason for RoE is to avoid unnecessarily complicated solutions and possibilities for defects. Don'​t ​lose sight of that goal.
   * [[Model Principle]] (MP): RoE states that [[anti-patterns:​primitive obsession]] shall be avoided. Instead more specific types should be used in parameter lists. MP makes this even clearer: In object-orientation objects instead of plain integers or strings are used.   * [[Model Principle]] (MP): RoE states that [[anti-patterns:​primitive obsession]] shall be avoided. Instead more specific types should be used in parameter lists. MP makes this even clearer: In object-orientation objects instead of plain integers or strings are used.
   * [[Law of Leaky Abstractions]] (LLA): Often abstractions create a level of implicitness. Abstraction leaks are one reason why explicit solutions can be considered preferable.   * [[Law of Leaky Abstractions]] (LLA): Often abstractions create a level of implicitness. Abstraction leaks are one reason why explicit solutions can be considered preferable.
principles/rule_of_explicitness.1375617889.txt.gz · Last modified: 2013-08-04 14:04 by christian