Game Development Reference
In-Depth Information
On the other side of the fence, developers working on the user interface only have
to know that any files added to a collection in the object model are to be displayed
in the appropriate controls. They do not care where these files come from, just so
long as they are notified accordingly when files are made available for display.
Another nice feature of a decoupled object model is the ability to distribute
responsibility for the implementation of certain aspects to different developers
without their having to worry about how the other components work. Again, as
long as the appropriate notifications are fired, the villagers are content. If you have
a developer who shows the file listing in a tree view, she will not care about another
developer who shows the same listing in an HTML page that is generated with XSL
transforms. Both developers only care that the object model contains model
objects that will fire the appropriate notifications when certain situations arise.
Lastly, having an object model that supports automation is a godsend to func-
tional and defect testing. It is very easy to write scripts to test user interface and
business logic behaviors when the underlying architecture supports this automa-
tion natively.
Comparison with Model-View-Controller Pattern
To start, it is important to cover the Model-View-Controller (MVC) pattern before
doing a comparison because this chapter discusses a slightly enhanced version of
MVC. The MVC pattern, or paradigm, encompasses breaking a section or all of an
application into three parts: the model, the view, and the controller.
The model manages information and handles the notification of observers when
the related information changes. The model only contains information and func-
tionality that match a common purpose. If you need to model multiple groups of
unrelated information and functionality, you create multiple models. This is
important so that your business logic remains modular and decoupled. The model
serves as an abstraction of a real world system or process. As an example, a model
could be a relationship between file and directory entries, and could contain func-
tionality to load them from the file system or network. There is no user interface
code for displaying the entities within the model; the user interface code is han-
dled by the views.
The view handles transforming the models to be displayed in an appropriate dis-
play context. A view is usually attached to a single display surface and renders to
that surface using transformed information from the models attached to it. The
view automatically renders the information again when the information in the
model changes. It is quite common to have multiple views attached to the same
Search Nedrilad ::




Custom Search