Game Development Reference
time constraints. The ideal solution to this problem would be a solid and proven
design from the ground up that would pave the way for flexible extensibility sup-
port. Typically, rich object models that support extensibility are developed with
respect to the Model-View-Controller design pattern, but this chapter will present
a slight deviation from this common approach, using .NET delegates to provide a
truly decoupled architecture. This chapter will also show how to embed a com-
mand window, such as the one found in Visual Studio .NET, to write and execute
script macros at runtime within the application.
Advantages of an Automatable Object Model
Many benefits are derived from developing an object model that supports automa-
tion, but I will list only a handful of them since that should be enough to convince
you. One of the biggest benefits is that a rich object model decouples the user
interface from the business logic. Quite often, the user interface is entangled with
business logic and becomes hard to maintain. The user interface code can be so
dependent on the business logic that a single change to the business logic can
break the entire application, and vice versa for changes to the user interface code.
This occurrence is generally a result of developers focusing first on the user inter-
face when they are assigned a task. Building the user interface, even a rough pro-
totype, before the business logic is a bad idea because the design of your business
logic will reflect the constraints and design ideas behind the way your user inter-
face is designed. Business logic should be user interface-agnostic.
A rich object model causes developers to focus on the design behind small units of
work instead of the entire application, or “the big picture.” Focusing on a small
unit of work usually results in cleaner and more reliable code. For example, imag-
ine a part of the application that shows the user a file listing in a tree view.
Normally, a developer would design the system with the tree view control in mind.
A developer thinking about the object model, however, would ignore the fact that
there is a user interface. He would focus strictly on file and directory entities, pro-
cessing functionality such as determining a hierarchical list of files and folders
from a parent folder, and how these entities fit into the rest of the model. The new
functionality in the object model can then be consumed by whatever component
is using it, in this case the user interface of the application. The developer could
now display this relationship of entities in multiple tree view controls, or other
controls altogether, without altering the model. If the user interface had been con-
sidered, he might have been stuck with file loading code mixed in with the code of
the tree view control, forcing him to copy and paste code or refactor.