Game Development Reference
solution is that the represented entity is partitioned across multiple frameworks.
Another improvement to this solution is to use an aggregate class that contains all
the subclasses and facilitates the communication and conversion between parts.
Cause: Legacy Components
There are times when the classes in a framework do not satisfy the problem
domain solution, and the design warrants that a legacy component be used in con-
junction with a framework to fill the gap. This situation can also arise if there is
considerable time and expense invested in a legacy component (such as a game
engine or utility library), and a business decision is made to reuse existing tech-
nology within a new framework (unmanaged and managed interoperability, for
example). Using legacy components can cause severe compositional friction in
your framework unless dealt with accordingly.
One method of removing the composition implications is to modify the frame-
work to reference the legacy component instead of classes within the framework,
though this solution requires access to the source code.
An alternative solution is to employ the adapter pattern and build a class that lies
between the framework and the legacy component, acting as an interpreter so that
both parts can communicate with each other. The latter part of this chapter focus-
es on this method in much greater detail.
Cause: Source Code Access
Quite often, multiple frameworks are developed by multiple teams, and develop-
ment rules regulate that a certain team only has access to their own source code,
and can only access functionality in the other frameworks using the public interfaces
of compiled libraries or assemblies. This constraint is good in that it restricts each
team from having a varying source code version of another team's framework, but
there is a problem as well. There are times when behavior must be added to anoth-
er framework to allow for communication between the other frameworks.
Without access to source code, each team must send numerous waves of change
requests to the other teams, asking for modifications, and then other issues may arise
when the public interfaces do not satisfy the needs of the team that requested them.
One solution to this problem is the use of wrappers encapsulating an external
framework and attempting to build new functionality on top of the existing
library. This approach has some problems though, such as considerable amounts
of additional code and severe performance penalties. Additionally, if any logic is