2.9.1 Domain Objects (or Models)

Doing Object Oriented (OO) implementation implies the system you are creating revolves around objects; in the case of Python applications, we use the word `instances'. OO applications call the instances that represent your problem's logical entities 'domain objects'. In a mail application, for instance, you might have Person and Message domain objects; in a sales application you could have Product and Sale.

Picking up from our last example, you could say NewsItem represented a class of domain objects, since its instances held data (or `state') that represented a logical container relevant to the task we had at hand, browsing news. This example was very simple, and there was no mechanism coded into the NewsItem class, but the concept is the same.

One very common problem when coding a new UI to manipulate the information in a domain object - at the fundamental level, in an instance - is the amount of code that needs to be done to alter the state of the instance. If you have a small form, with few controls in it, it's merely a bother; if you have a complex form, with many controls and lots of interaction, it can be a nightmare of accessors and message passing. Each widget must have the appropriate signals connected, and the handlers must either manipulate the instance directly, or call accessors repeatedly. Changing the UI involves more coding and complication.

So, in summary:



Footnotes

... model6
A note on naming: in MVC, one third of the triad is called Model, which (I believe) is short for Application Model. In theory, the Application Model represents the real-world behavior of your application, just like the domain object; synonyms, basically. Some authors, however, defend that the Application Model and the domain object should be separate entities. I don't think this is necessarily true. From my experience, in most cases the two are functionally equivalent (and separating them showed me that I ended up doing was proxying calls from one to the other).