Principles Wiki

User Tools

Site Tools

You are here: Principles Wiki » Principles » Model Principle (MP)
principles:model_principle

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
principles:model_principle [2018-12-08 10:35] – [Strategies] christianprinciples:model_principle [2018-12-08 10:43] – [Description Status] christian
Line 33: Line 33:
 When the structures in the software roughly correspond to the structures of the problem domain, a developer doesn't have to learn both of them. Knowing the problem domain is inevitably necessary. Any further structure of the software has to be learned and understood in addition. So creating a direct mapping between them, makes understanding the software easier, which improves maintainability. In such a system for most functionality there is a "natural", i.e. an intuitively clear place to implement it. This makes structuring the software easier and helps finding the implementation for a given functionality. When the structures in the software roughly correspond to the structures of the problem domain, a developer doesn't have to learn both of them. Knowing the problem domain is inevitably necessary. Any further structure of the software has to be learned and understood in addition. So creating a direct mapping between them, makes understanding the software easier, which improves maintainability. In such a system for most functionality there is a "natural", i.e. an intuitively clear place to implement it. This makes structuring the software easier and helps finding the implementation for a given functionality.
  
-Moreover if something works accidentally, it breaks accidentally. In the example above supplying a ''Product'' to the ''cancelOrder'' method only works because by some circumstance it is made sure that  when ''cancelOrder'' is called, there is only one order for that particular product. It's a hidden precondition. As the software is changed, this hidden precondition may not be guaranteed anymore. This results in a non-obvious bug in a part of the system you haven't directly touched. Similarly in the ''deleteOrder'' example: The ''cancelOrder'' operation might get enhanced by creating a reverse invoice, a credit note, or a message to the customer. But an order might have to be deleted for purely technical reasons (migration to a new order system, etc.). So if you call ''cancelOrder'' instead of ''deleteOrder'' this will produce nasty bugs if ''cancelOrder'' gets enhanced as described.+Moreover if something works accidentally, it breaks accidentally. Many many bugs are created because you are not precise with semantics. 
 + 
 +In the example above supplying a ''Product'' to the ''cancelOrder'' method only works because by some circumstance it is made sure that  when ''cancelOrder'' is called, there is only one order for that particular product. It's a hidden precondition. As the software is changed, this hidden precondition may not be guaranteed anymore. This results in a non-obvious bug in a part of the system you haven't directly touched. Similarly in the ''deleteOrder'' example: The ''cancelOrder'' operation might get enhanced by creating a reverse invoice, a credit note, or a message to the customer. But an order might have to be deleted for purely technical reasons (migration to a new order system, etc.). So if you call ''cancelOrder'' instead of ''deleteOrder'' this will produce nasty bugs if ''cancelOrder'' gets enhanced as described. 
 ===== Strategies ===== ===== Strategies =====
  
Line 117: Line 119:
 /* Choose one of the following and comment out the rest: */ /* Choose one of the following and comment out the rest: */
 /*[[wiki:Stub]]*/ /*[[wiki:Stub]]*/
-[[wiki:Incomplete]] +/*[[wiki:Incomplete]]*/ 
-/*[[wiki:Complete]]*/+[[wiki:Complete]]
  
  
principles/model_principle.txt · Last modified: 2021-10-18 21:47 by christian