Which approach do I choose for representing objects and scenes in my 3D drawing library?

Question

I'm creating my own drawing library in C++ to provide shared rendering code for my projects.

Since the library is designed to be used as a component of other projects, the renderer's representation of 3D objects and scenes will be "attached" to whatever the program's native representation of an "object" or "scene" is. Then, the renderer will use this scene information to draw all the objects.

There are two approaches I could go with. The first approach would involve assigning each drawable object in my program (for this example, let's call our program's objects ProgramObject) a Drawable member from the drawing library. Then, whenever a ProgramObject is created, it gets added to a list in an instance of the program's "scene" class (let's call this one ProgramScene), which can then add the ProgramObject's Drawable member to it's DrawableScene member. The ProgramScene can register its DrawableScene with the renderer for drawing. A Drawable contains information such as mesh data, materials, etc. The renderer consumes Drawables from a DrawableScene and uses them to construct a frame in OpenGL.

The second approach would be mostly the same, except instead of ProgramObject and ProgramScene having Drawable and DrawableScene members, ProgramObject and ProgramScene would inherit from Drawable and DrawableScene respectively.

Which approach would be better?

Answer 1

When in doubt, it is usually better to prefer composition over inheritance. Still, that is just a heuristic, not a law, and asking if this heuristic applies to your specific case is definitely justified.

Here is a simple argument why I think you should prefer composition in this case: if you want to keep your design open to make Drawable a base class of certain more specific "drawables" inside your library (like 2D or 3D drawables, or OpenGL vs. DirectX drawables, or some other kind of technical classification), use composition. That will allow it to let the technical inheritance hierarchy stay orthogonal with any kind of domain specific inheritance hierarchy outside your library, where ProgramObject may be the base class of certain domain specific classes (like a player character, or a vehicle, or some kind of other object).

This article here calls these aspects different dimensions:

When you have a situation where either composition or inheritance will work, consider splitting the design discussion in two:

• The representation/implementation of your domain concepts is one dimension
• The semantics of your domain concepts and their relationship to one another is a second dimension

In general, inheriting within one of these dimensions is fine. The problem becomes when we forget to separate the two dimensions, and start inheriting across inter-dimensional boundaries.

And this is exactly what would happen when you start to inherit a ProgramObject from a Drawable: you would mix up the "drawing" dimension with domain concepts ("dimensions"), which can easily lead to a very unflexible design, where one will run into trouble when trying to separate technical and domain specific concerns.

Let me add that there scenarios where inheriting from Drawable in an application context can make sense - when the library is designed to allow specific drawables (seen as extensions in the technical dimension) in an application. But I guess you would not call this subclass a ProgramObject anymore.