Game Development Reference
In-Depth Information
A different programmer might view your masterpiece entirely differently, however.
For example, intricate relationships inside a class hierarchy could be difficult or
impossible to understand without your personal guidance. Documentation, usually
written in haste, is almost always inadequate or even misleading.
To help you avoid some of the common design practice pitfalls, I
m going to spend
some time in this chapter up-front discussing how you can do the following:
'
n
Avoid hidden code that performs nontrivial operations.
n
Keep your class hierarchies as flat as possible.
n
Be aware of the difference between inheritance and composition.
n
Avoid abusing virtual functions.
n
Use interface classes and factories.
n
Encapsulate the components of your system that are most likely to change.
n
Use streams in addition to constructors to initialize objects.
Copy constructors, operator overloads, and destructors are all party to the
”
hidden code problems that plague game developers. This kind of code can cause
you a lot of problems when you least expect. The best example is a destructor
because you never actually call it explicitly. It is called when the memory for an
object is being deallocated or the object goes out of scope. If you do something really
crazy in a destructor, like attach it to a remote computer and download a few mega-
bytes of MP3 files, your teammates are going to have you drawn and quartered.
My advice is that you should try to avoid copy constructors and operator overloads
that perform nontrivial operations. If something looks simple, it should be simple
and not deceptive. For example, most programmers would assume that if they
encountered some code that contained a simple equals sign or multiplication symbol
that it would not invoke a complicated formula, like a Taylor series. They would
assume that the code under the hood would be as straightforward as it looked
“
nasty
—
a
basic assignment or calculation between similar data types like
floats
or
doubles
.
Game programmers love playing with neat technology, and sometimes their sense of
elegance drives them to push nontrivial algorithms and calculations into C++ con-
structs, such as copy constructors or overloaded operators. They like it because the
high-level code performs complicated actions in a few lines of code, and on the sur-
face, it seems like the right design choice. Don
'
t be fooled.
