Game Development Reference
little to no compositional friction. However, when considerable domain overlap
occurs, there are some important decisions to make. Sometimes it would be more
advantageous to rewrite one or both of the frameworks from scratch when frame-
work reuse is threatened. It can be more problematic to refactor communication
between both frameworks when the expected lifetime of the product is quite long.
If an application using the frameworks will be evolving over a long period of time,
the frameworks must be continuously updated for each consecutive version of the
application. Remember to make your decision based on the problem domain and
the coverage of the framework.
Cause: Design Intentions
A well known design philosophy is that reusable software must be written for reuse
through composition and adaptation. Generally, frameworks are designed to be
reused through adaptation, but not through composition. Designing software
reusability through composition is very important, and there are two composition
directions that can occur. The first direction is parallel composition, which targets
frameworks that exist on the same layer in the application. Parallel is the easiest
composition direction because both frameworks do not rely directly on the ser-
vices each other provides to properly operate. The other composition direction is
perpendicular, which exists in a software application that supports a layered archi-
tecture where frameworks can depend on services provided by another framework
in a different layer. One issue that is independent of the composition direction is
the communication support, which can be either half-duplex (one-way, or sim-
plex) or full-duplex (two-way). Half-duplex communication is fairly easy to
design for, but full-duplex communication can present additional design prob-
lems when composing multiple frameworks.
Cause: Framework Gap
A framework gap occurs when multiple frameworks need to be composed to sat-
isfy requirements, but both frameworks do not completely cover the requirements.
This problem typically occurs because each framework does not have ample
domain coverage, leading to domain gaps or overlaps.
There are a few solutions to this problem, the first one being the use of wrapper
class that encapsulates the existing functionality and extends any missing func-
tionality, also providing a uniform public interface so that clients are unaware of
the internal architecture.