Game Development Reference
the code that Word invokes to change a document title. You can instead find the
Document instance in the Application.Documents collection and modify the Name
property. The user interface will automatically reflect the new change, thanks to
the power of an object model that supports automation.
Prior to learning the Model-View-Controller paradigm, I used to think that large
applications like Word or Visual Studio just had a massive amount of code that
performed a whole slew of tasks when an event, such as a file being deleted,
occurred. The complexity and unmaintainability of such a solution gave me shivers.
When I discovered this wonderful pattern, I began to relax and understand that
these applications are actually not that complicated. But experience and learning
from past mistakes is the way to constantly improve and write better code.
The object model for the example in this chapter is far from a real world system.
Instead, it exists solely to show how all the pieces fit together into an architecture
that has decoupled views from the model, and automation script support using
the CodeDom compiler. Showing a full-featured object model in this chapter would
make it even more difficult to understand the underlying principles behind what
this chapter really covers.
The actual implementation details behind the example on the Companion Web
site are covered near the end of this chapter.
I will not talk much about plugin architectures, since this topic is addressed in Chapter
38, “Designing an Extensible Plugin-Based Architecture.” I will, however, discuss
how a robust object model can make your life much easier when building a system
that supports plugin extensibility.
When it comes to extensibility, having a rich object model that supports automa-
tion is ideal for plugin-based architectures. Theoretically, if your object model is
robust enough that you can perform all tasks programmatically, any plugins that
are exposed to this object model can extend all aspects of the application.
Supporting extensibility with a rich object model and plugins reduces the amount
of code that exists in the core assemblies, resulting in a number of advantages. The
first advantage is that your working set is greatly reduced, only loading plugins
when needed (provided you are unloading the assemblies from a second applica-
tion domain when they are no longer in use). A reduced working set results in less
memory being required to run your application, and overall loading and execution
times are reduced.