principles:model_principle
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
principles:model_principle [2013-02-10 23:01] – [Contrary Principles] +HC christian | principles:model_principle [2021-10-18 21:47] – old revision restored (2019-12-31 20:31) christian | ||
---|---|---|---|
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 17: | Line 21: | ||
===== Description ===== | ===== Description ===== | ||
- | The software should model and mirror the "real world" | + | The software should model and mirror the "real world" |
Real world actions are then // | Real world actions are then // | ||
- | FIXME more detailed description | + | Be precise with semantics. An operation '' |
+ | Keep sure that your software models the reality by invoking the method that has the correct semantics and supplying it with the parameters that are needed from a requirements perspective. | ||
===== Rationale ===== | ===== Rationale ===== | ||
Line 28: | Line 33: | ||
When the structures in the software roughly correspond to the structures of the problem domain, a developer doesn' | When the structures in the software roughly correspond to the structures of the problem domain, a developer doesn' | ||
+ | Moreover if something works accidentally, | ||
+ | In the example above supplying a '' | ||
===== Strategies ===== | ===== Strategies ===== | ||
Line 34: | Line 41: | ||
* Create methods corresponding to real-world actions | * Create methods corresponding to real-world actions | ||
* 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 | + | * For artificial behavior that cannot be mapped to a natural class at least create a metaphor or an artificial model (like a state machine) |
+ | * Be precise with semantics. If you have an operation that currently does what you need but for slightly different reasons because it's an operation on the wrong abstraction level, create a new operation with the correct semantics. Have that new operation call the existing one as an implementation detail (e.g. have a '' | ||
+ | |||
+ | ===== 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 56: | ||
> " | > " | ||
- | 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 81: | ||
* [[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. | + | * [[Law of Leaky Abstractions]] (LLA): When building abstractions |
==== Principle Collections ==== | ==== Principle Collections ==== | ||
Line 80: | Line 93: | ||
{{page> | {{page> | ||
- | ===== Example | + | ===== Examples |
==== Example 1: Object Structure (Library) ==== | ==== Example 1: Object Structure (Library) ==== | ||
Line 94: | Line 107: | ||
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 '' | ||
+ | |||
+ | |||
+ | ==== Example 4: Brake and Air Conditioning ==== | ||
+ | |||
+ | Suppose a car has an air conditioning and a hill start assistant. The air conditioning needs to make sure that the engine provides enough power on sunny days. So it measures its power-consumption and pushes down the gas pedal just enough to the engine isn't stalled. The hill start assistant automatically releases the hand brake if you start driving. Now the following situation can happen: A car waits in front of a boom barrier of an underground garage. It's a hot day and the driver opens the window to get the ticket. hot air flows into the car and the A/C powers up. The revolution speed is low because the car stands still so the A/C hits the gas pedal in order not to stall the engine. Now the hill start assistant realizes that the gas pedal was pressed and releases the hand brake because pressing the gas pedal is the trigger that the diver want to drive away. As a result the car crashes into the boom barrier. | ||
+ | |||
+ | The problem here is with the A/C. Semantically it wanted to increase the motor power but actually it called an operation that hit the gas pedal. This is almost the same but not exactly the same. It's an operation on the wrong level of abstraction. If the A/C had called an operation '' | ||
+ | |||
+ | |||
+ | ==== Example 5: Inferring Information ==== | ||
+ | |||
+ | Suppose there is a smartphone app and its backend. The app lets you buy several products. One day the app developers demand that the backend adds a field describing the product size (small, medium, large). The backend developers add the field and everyone is happy. The app developers use this field so they can decide whether gift wrapping is available (large products cannot be gift-wrapped). Half a year later the company decides to enhance their product portfolio by reselling products of company B. The backend will redirect orders of B-products directly to company B so they are in charge of delivery. | ||
+ | |||
+ | Unfortunately B is not able to provide gift-wrappings at all. So the smartphone app has to be changed such that it not only removes the gift-wrapping option for large products but also for B-products. But smartphone apps need to be updated by the customer (and some of them never do). So the only way to ensure that gift-wrapping is handled correctly even if the customer hasn't updated yet, is that the backend returns '' | ||
+ | |||
+ | The '' | ||
Line 99: | Line 135: | ||
/* Choose one of the following and comment out the rest: */ | /* Choose one of the following and comment out the rest: */ | ||
/ | / | ||
- | [[wiki: | + | /*[[wiki: |
- | /*[[wiki: | + | [[wiki: |
Line 111: | Line 147: | ||
* [[http:// | * [[http:// | ||
+ | ===== Discussion ===== | ||
+ | |||
+ | Discuss this wiki article and the principle on the corresponding [[talk: |
principles/model_principle.txt · Last modified: 2021-10-18 21:47 by christian