Should I attempt to fix an arguably poor design decision in a 3rd party library?

Question

My project involves Qt plus and unnamed 3rd party physics simulation library. The way the physics library works is that physical bodies cannot create themsleves; the "world" must instantiate them so that they can be added to the world immediately.

My project creates a wrapper around these physical bodies to add some extra functionality, but because it stores these physical bodies it can't be instantiated either. The first question is, does it make more sense to allow these bodies to stand on their own? The part that I find awkward is that I have to pass a reference to the world to the object so that it can be created, when, to me, it makes more sense to pass the object to the world.

To fix this, I can delay the creation of the 3rd party body until it is added to my world wrapper. But that means my world wrapper becomes in charge of initializing the body correctly. It also means that I can't really access any of the properties of the object until it's added to the world anyway, because they all rely on the 3rd party body being initialized... unless I duplicate all that data and then pass it off to the library when it's added.

Is it worth the effort, or should I just continue to pass a pointer to my world wrapper so that my body wrapper can be created?

I mention Qt, because the way the Qt graphics framework works is that you can create QGraphicsItems whenever you want, and they'll stand on their own, but they just won't be visible until you add them to the scene. The analogy here is that GraphicsItem == Body, and Scene == World.

Answer 1

To be truely effective, a facade pattern (your wrapper) has to hide the underlying details of the implementation from the user of the facade. This does mean using data transfer objects to hold the data. Facades can be cumbersome to implement but they give you the ability to change out the underlying implementation without affecting the end user.

sudo code:

Rock rock = new Rock(100); //simple data container for now.

PhysicsFacade f = new PhysicsFacade(); //internally creates world.

f.DoSomething(rock); //internally rock's data used by world to create an equivalent    object which is attached to the rock data container for future use.

Answer 2

all my getters and setters basically need to check "has the body been initialized yet?"

If you're using Qt I suppose you're using C++.

I don't know Qt and I don't know why you want to change the existing mechanism, but anyway: one thing you can do in C++, that may be useful to you, is overload the -> operator to access your objects. When someone invokes the -> operator, the operator can also create the object just-in-time if it hasn't already beein instantiated, something like:

World& getWorld();

class Body;

class MyWrapper
{
  Body* m_body;

public:

  MyWrapper() : m_body(0) {}

  Body* operator->()
  {
    if (!m_body)
    {
      m_body = new Body(getWorld());
    }
    return m_body;
  }

  ... etc ...
};

---

Edit

What do you mean, "change the existing mechanism"? The one that the physics library has laid out? I think I mentioned my reasons.

Yes.

With your solution... what does getWorld() do? Is that a global function? If world is floating around in global space, then there isn't really a problem, I can just instantiate the body at the same time MyWrapper is instantiated.

Yes it returns a reference to the World, which is what you need to create a body in the physics library. It's an example, I don't know where you're getting your World reference from, nor when.

But what if the world still doesn't exist at the point that the -> operator is used? I'm not really sure this solves anything. Not to mention that one way or another, you're still passing the world to the body

Maybe getWorld will throw an exception if it's called too early. Anyway, what this was supposed to buy you was:

• The ability to create your MyWrapper instances without a World reference and perhaps before the world is created.

• The ability to create a Body instance just-in-time when a client tryied to access any of the Body's propeties or methods

The -> operator is what clients would using to get at the physics body which you're wrapping: like a "smart pointer".

It might be easier to understand and/or to suggest solutions for your problem if you'd illustrate your problem with some pseudocode.

Not to mention that one way or another, you're still passing the world to the body

You said that was a requirement of the underlying library. When you said, "Should I attempt to fix", I thought you meant "Shall I implement a different API in my wrapper, and hide the existing API within the my private implementation?" It didn't occur to me that you might try to change (not just wrap) the existing implementation.

Answer 3

Before I share my answer, let me rename a few things. "Object" is the thing that holds the "physics body". "World" is the thing that holds the "physics world". Again, only the "physics world" can create the "physics body" (its constructor is private).

Here's what I've done. The Object simply holds a pointer to the physics body. That way you can create Object whenever you want, and play with all it's data without even needing a world... you just can't touch the properties directly related to physics body (I'm going to ASSERT this).

The World finishes instantiating the Object (ie the physics body) as soon as it's added to the World. This perhaps breaks a tiny bit of OOP because the world has to manipulate a few of the Objects varibales to do so (I've made it a friend) but I think it's the least of the evils.