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-10 22:55] – [Complementary Principles] IE => TdA/IE christian | principles:model_principle [2021-09-02 20:01] – old revision restored (2021-05-11 22:08) 65.21.179.175 | ||
---|---|---|---|
Line 3: | Line 3: | ||
===== Variants and Alternative Names ===== | ===== Variants and Alternative Names ===== | ||
- | * Direct Mapping((Bertrand Meyer: //[[http:// | + | * Direct Mapping(({{page> |
+ | * Low Representational Gap (LRG)((Craig Larman: //[[resources:Applying UML and Patterns]]//, p 281)) | ||
===== Context ===== | ===== Context ===== | ||
/* fill in contexts here: */ | /* fill in contexts here: */ | ||
- | * [[contexts: | + | * [[contexts: |
+ | * [[contexts: | ||
+ | * [[contexts: | ||
+ | * [[contexts: | ||
Line 35: | Line 39: | ||
* 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 53: | ||
> " | > " | ||
- | 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 66: | Line 76: | ||
* **[[Encapsulate the Concept that Varies]] (ECV)**: Sometimes there are " | * **[[Encapsulate the Concept that Varies]] (ECV)**: Sometimes there are " | ||
* [[Keep It Simple Stupid]] (KISS): There are often simpler ways to build a software system than to model and mirror the real world behavior, which frequently means having more objects and more complicated structures. | * [[Keep It Simple Stupid]] (KISS): There are often simpler ways to build a software system than to model and mirror the real world behavior, which frequently means having more objects and more complicated structures. | ||
- | * [[Single Responsibility Principle]] (SRP): Following the Model Principle | + | * [[Single Responsibility Principle]] (SRP): Following the Model Principle |
+ | * [[High Cohesion]] (HC): MP sometimes creates classes with suboptimal cohesion. See also SRP. | ||
==== Complementary Principles ==== | ==== Complementary Principles ==== | ||
Line 72: | Line 83: | ||
* **[[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 90: | ||
{{page> | {{page> | ||
- | ===== Example | + | ===== Examples |
==== Example 1: Object Structure (Library) ==== | ==== Example 1: Object Structure (Library) ==== | ||
Line 94: | Line 104: | ||
Furthermore buttons, check boxes, text fields, and the like are also models of concepts in the real world. Buttons are typical controls of machines and check boxes and text fields are parts of a typical (paper-based) form. So the class '' | Furthermore buttons, check boxes, text fields, and the like are also models of concepts in the real world. Buttons are typical controls of machines and check boxes and text fields are parts of a typical (paper-based) form. So the class '' | ||
+ | |||
+ | |||
+ | ==== Example 3: Dependencies ==== | ||
+ | |||
+ | MP also tells which modules may depend on which others. Suppose we have a software comprising a parser for mathematical functions. Obviously there will be classes '' | ||
+ | |||
+ | On the other hand our intuitive model of parsers and functions tells us that a '' | ||
principles/model_principle.txt · Last modified: 2021-10-18 21:47 by christian