Poisoned by Pointers

The past few days at work I've been wrestling with an unruly¹ interface which bridges two simulation frameworks. At the interface boundary, our local libraries have been pruned down to a few dozen hierarchical object pointers in nested objects, coupled with nontrivial initialization of state of each object. The sim I'm integrating with is characterized as a mini-soa² which leverages a modified adevs event simulator as a driver and communication hub. With a rapidly approaching deadline I have taken to coding all sorts of hacks³ that I never would have implemented on calmer days. Alas, the calm days are far fewer than the hectic ones with little hope of change.

Pesky Polymorphism

The architectures I'm connecting are both highly flexible and extensible. Most of the models, objects and services are polymorphic, ie you could replace a FixedPlatform, with a MovingPlatform and still call either of their Platform::Position() methods from a base class pointer.

But neither of these large frameworks are amenable to integration. Their interfaces and internal data structures diverge enough that sharing inheritance from joint parents would be disastrous. It's like mixing oil and water, and I'm working to squeeze my models into the gap between their surfaces.

The irony is that the underlying data and physics is common to both simulations by design. They both emulate physical and geometric constraints. Once I get past the individual implementations and relative calculations both frameworks are bound by gravity, object position, velocity, acceleration and orientation.

The major differences between the design of the two code bases is how data is treated. In one framework state is separated from model and service functionality by a strict interface, while in the other objects often have local state information to support encapsulated transformations. Each has its advantages and limitations, but they certainly don't flow well together.

Notes:

1. by unruly I mean slightly more complicated than I'd prefer. The software I'm working with is flexible, it's just that neither architecture is amenable to integration with other frameworks
2. mini-soa stands for mini service oriented architecture, as it lacks the automated service registration that a full soa has. The adevs simulator is well documented but has been modified heavily by the group I'm working with
3. The sins I've committed this week include but are not limited to mutable members modified in const calls, static globals, flag based initialization logic instead of moving code to constructors, initializing from truth, and shoving references to truth into measurement data. Every single good habit has been tossed carelessly to the wind to get the code up and running.