principles:model_principle
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:model_principle [2013-02-11 11:18] – +Example 3 (depedencies) christian | principles:model_principle [2021-09-02 12:34] – old revision restored (2021-05-11 22:08) 65.21.179.175 | ||
---|---|---|---|
Line 4: | Line 4: | ||
* Direct Mapping((Bertrand Meyer: // | * Direct Mapping((Bertrand Meyer: // | ||
+ | * Low Representational Gap (LRG)((Craig Larman: //Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development//, | ||
===== Context ===== | ===== Context ===== | ||
/* fill in contexts here: */ | /* fill in contexts here: */ | ||
- | * [[contexts: | + | * [[contexts: |
+ | * [[contexts: | ||
+ | * [[contexts: | ||
+ | * [[contexts: | ||
Line 35: | Line 38: | ||
* Map additionally necessary behavior to natural classes instead of creating artificial classes | * Map additionally necessary behavior to natural classes instead of creating artificial classes | ||
* For artificial behavior that cannot be mapped to a natural class at least create a metaphor or an artificial model (like for example a state machine) | * For artificial behavior that cannot be mapped to a natural class at least create a metaphor or an artificial model (like for example a state machine) | ||
+ | |||
+ | |||
+ | ===== Caveats ===== | ||
+ | |||
+ | This principle may lead to the problem of modeling the real world in too great detail. This complicates the design without giving any further benefits. Especially a wrong understanding of inheritance may lead to [[anti-patterns: | ||
+ | |||
+ | See also section [[#contrary principles]]. | ||
Line 42: | Line 52: | ||
> " | > " | ||
- | Although this view is disputed as a definition for object-oriented programming, | + | Although this view is disputed as a definition for object-oriented programming, |
===== Evidence ===== | ===== Evidence ===== | ||
/* Comment out what is not applicable and explain the rest: */ | /* Comment out what is not applicable and explain the rest: */ | ||
/* * [[wiki: | /* * [[wiki: | ||
- | /* * [[wiki: | + | /* * [[wiki: |
- | * [[wiki: | + | * [[wiki: |
- | * [[wiki: | + | * [[wiki: |
Line 68: | Line 77: | ||
* [[Single Responsibility Principle]] (SRP): Following the Model Principle sometimes results in classes having more than just one responsibility. | * [[Single Responsibility Principle]] (SRP): Following the Model Principle sometimes results in classes having more than just one responsibility. | ||
* [[High Cohesion]] (HC): MP sometimes creates classes with suboptimal cohesion. See also SRP. | * [[High Cohesion]] (HC): MP sometimes creates classes with suboptimal cohesion. See also SRP. | ||
+ | |||
==== Complementary Principles ==== | ==== Complementary Principles ==== | ||
* **[[Tell, don't Ask/ | * **[[Tell, don't Ask/ | ||
* [[Low Coupling]] (LC): When designing a model for a software, it has to be borne in mind that structures with low coupling are desirable. | * [[Low Coupling]] (LC): When designing a model for a software, it has to be borne in mind that structures with low coupling are desirable. | ||
- | * [[Easy to Use and Hard to Misuse]] (EUHM): The Model Principle tells to design the operations of a class according to the model. While doing so, EUHM has to be kept in mind, too. | ||
Line 80: | Line 89: | ||
{{page> | {{page> | ||
- | ===== Example | + | ===== Examples |
==== Example 1: Object Structure (Library) ==== | ==== Example 1: Object Structure (Library) ==== |
principles/model_principle.txt · Last modified: 2021-10-18 21:47 by christian