This is an old revision of the document!
Table of Contents
Model Principle (MP)
Variants and Alternative Names
- Direct Mapping1)
Context
Principle Statement
The object structure of the software should model and mirror those concepts and actions of the real world, that the software supports.
Description
The software should model and mirror the “real world”. This first of all means, that the structure of the software—to some extend—models the structure of the problem. When the “real world action” that the software should support comprises certain entities like e.g. customers, products, and orders, then there should be one object for each customer, product and order. Furthermore there should be one class for each concept. And if there is a certain relationship between customers, orders, and products, there should also be an association between the corresponding classes and references between the objects. So the object structure models the structure of the real world concepts.
Real world actions are then mirrored in the software system. This means that each action in the real world triggers a corresponding action in the model world which ensures that the model stays consistent with the real world. So the software is a kind of a simulation of what actually happens. If customer orders some product, the software reacts by creating an order object, which is connected to the customer and the product objects corresponding to the customer and the product involved in the real world action.
more detailed description
Rationale
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.
Strategies
- Create a class for each relevant real-world concept (“natural classes”)
- Create methods corresponding to real-world actions
- 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)
Origin
The root of this principle is the very beginning of object-orientation itself. The idea behind Simula, the first object-oriented programming language, was to view program executions as simulations. Kristen Nygaard, one of the creators of Simula defines object orientation as follows:
“Object-oriented programming. A program execution is regarded as a physical model, simulating the behavior of either a real or imaginary part of the world.”2).
Although this view is disputed as a definition for object-oriented programming, it became the key idea of object-oriented analysis. (maybe mention Grady Booch?)
Evidence
examined?
- Accepted: Virtually every introduction to object-oriented analysis roughly explains this but mostly without stating it as a principle.
- Questioned: The value of this principle is disputed. It is questioned whether objects in the OOP sense nicely map to real-world objects3). Furthermore there is the typical object-relational impedance mismatch4) and the observation that business rules sometimes are cross-cutting5). There also is not one single obvious model for the “real world”. A model is subjective to the one building the model. So it is not enough to model the “real world” but how to model it6).
Relations to Other Principles
Generalizations
Specializations
Contrary Principles
- Encapsulate the Concept that Varies (ECV): Sometimes there are “concepts that vary” which are not directly related to a real-world concept. So ECV demands having an artificial class.
- 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 sometimes results in classes having more than just one responsibility.
- High Cohesion (HC): MP sometimes creates classes with suboptimal cohesion. See also SRP.
Complementary Principles
- Tell, don't Ask/Information Expert (TdA/IE): TdA/IE tells how to distribute functionality among the natural classes which are created according to the Model Principle.
- 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.
Principle Collections
Example
Example 1: Object Structure (Library)
In a software system for a library, there will be a classes like Book
, Reader
, and Lending
. A reader has a name, a book has a title and the reader must return the book after some date of expiry. So the corresponding classes will have attributes describing these properties. The reader may borrow and return a book, so the Reader
class will have methods borrow()
and return()
. Classes, attributes, and methods are directly inferred from the problem domain.
Example 2: Swing
GUI frameworks like Java Swing typically have classes corresponding to the types of controls that can be used to build graphical user interfaces. So Swing for example has classes like JButton
, JCheckBox
, and JTextField
.
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 JCheckBox
is a model for a check box on the screen which itself is a model for a check box on a paper-based form.
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 Parser
and Function
. MP tells that dependencies between these classes shall be according to the model. Logically a parser parses a string and creates Function
objects. It is impossible to think about a Parser
without Function
s. So Parser
may naturally depend on Function
.
On the other hand our intuitive model of parsers and functions tells us that a Function
does not need a Parser
to be a meaningful entity. One can easily think of Function
s created by using builder functions instead of a parser. And even if that wasn't true and there would only be the possibility to create functions by using parsers, a Function
object logically can work without knowing that there are parsers which have created it. In an imaginary hierarchy of modules Parser would be a module on a higher scale than Function
. So MP forbids that Function
depends on Parser
.
Description Status
Further Reading
- ProgramsRepresentMentalModels (general discussion on mental models)
- SystemMetaphor (metaphors in extreme programming are a specific kind of model as discussed here)
- TheValueOfDomainModels (general discussion on domain models)
- Martin Fowler: AnemicDomainModel (the result of not properly adhering to the principle)
- Martin Fowler: Domain Logic and SQL (other possible to implement a system and their difference to domain models)