Differences

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

--- principles:model_principle [2021-09-02 12:34] – old revision restored (2021-05-11 22:08) 65.21.179.175
+++ 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 =====
-  * Direct Mapping((Bertrand Meyer: //[[http://en.wikipedia.org/wiki/Object-Oriented%20Software%20Construction|Object-Oriented Software Construction]]//))
+  * Direct Mapping(({{page>resources:Object-Oriented Software Construction#reference}}))
-  * Low Representational Gap (LRG)((Craig Larman: //Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development//, p 281))
+  * Low Representational Gap (LRG)((Craig Larman: //[[resources:Applying UML and Patterns]]//, p 281))
 ===== Context =====
 /* fill in contexts here: */
@@ Line 42: / Line 43: @@
 ===== 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:taxomania]], where an inheritance relation and the respective classes are only introduced because there seems to be such a taxonomy in the "real world"((Bertrand Meyer: //[[http://en.wikipedia.org/wiki/Object-Oriented%20Software%20Construction|Object-Oriented Software Construction]]//)). But inheritance should only be used on purpose, not just because it is possible. A special form of this problem is called [[anti-patterns:vapor classes]], which are useless abstractions which are never used((Robert C. Martin: //[[http://www.objectmentor.com/resources/articles/CoffeeMaker.pdf|Heuristics and Coffee]]//)).
+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:taxomania]], where an inheritance relation and the respective classes are only introduced because there seems to be such a taxonomy in the "real world"(({{page>resources:Object-Oriented Software Construction#reference}})). But inheritance should only be used on purpose, not just because it is possible. A special form of this problem is called [[anti-patterns:vapor classes]], which are useless abstractions which are never used((Robert C. Martin: //[[http://www.objectmentor.com/resources/articles/CoffeeMaker.pdf|Heuristics and Coffee]]//)).
 See also section [[#contrary principles]].
@@ Line 60: / Line 61: @@
   * [[wiki:Accepted]]: Virtually every introduction to object-oriented analysis roughly explains this but mostly without stating it as a principle. Bertrand Meyer explains this principle in his book //Object-Oriented Software Construction//
-  * [[wiki:Questioned]]: The value of this principle is disputed. It is questioned whether objects in the OOP sense nicely map to real-world objects((Lambda the Ultimate: //[[http://lambda-the-ultimate.org/node/3265|Why are objects so unintuitive?]]//, B. Jacobs: //[[http://www.geocities.com/tablizer/model.htm|OOP and "Modeling the Real World"]]//)). Furthermore there is the typical object-relational impedance mismatch((FIXME cite)) and the observation that business rules are sometimes cross-cutting(([[wiki>OopNotForDomainModeling]])). There also is not one single obvious model for the "real world". A model is subjective to the one creating the model. So it is not enough to model the "real world" but it is important to think about how to model it((Bertrand Meyer: //[[http://en.wikipedia.org/wiki/Object-Oriented%20Software%20Construction|Object-Oriented Software Construction]]//, p.694)).
+  * [[wiki:Questioned]]: The value of this principle is disputed. It is questioned whether objects in the OOP sense nicely map to real-world objects((Lambda the Ultimate: //[[http://lambda-the-ultimate.org/node/3265|Why are objects so unintuitive?]]//, B. Jacobs: //[[http://www.geocities.com/tablizer/model.htm|OOP and "Modeling the Real World"]]//)). Furthermore there is the typical object-relational impedance mismatch((FIXME cite)) and the observation that business rules are sometimes cross-cutting(([[wiki>OopNotForDomainModeling]])). There also is not one single obvious model for the "real world". A model is subjective to the one creating the model. So it is not enough to model the "real world" but it is important to think about how to model it((Bertrand Meyer: //[[resources:Object-Oriented Software Construction]]//, p.694)).