Home/ Questions/Q 9068815
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-16T17:17:00+00:00

I’ve been working on a small project using C++ (although this question might be

  • 0

I’ve been working on a small project using C++ (although this question might be considered language-agnostic) and I’m trying to write my program so that it is as efficient and encapsulated as possible. I’m a self-taught and inexperienced programmer but I’m trying to teach myself good habits when it comes to using interfaces and OOP practices. I’m mainly interested in the typical ‘best’ practices when it comes to accessing the methods of an object that is acting as a subsystem for another class.

First, let me explain what I mean:

An instance of ClassGame wants to render out a 2d sprite image using the private ClassRenderer subsystem of ClassEngine. ClassGame only has access to the interface of ClassEngine, and ClassRenderer is supposed to be a subsystem of ClassEngine (behind a layer of abstraction).

My question is based on the way that the ClassGame object can indirectly make use of ClassRenderer’s functionality while still remaining fast and behind a layer of abstraction. From what I’ve seen in lessons and other people’s code examples, there seems to be two basic ways of doing this:

  1. The first method that I learned via a series of online lectures on OOP design was to have one class delegate tasks to it’s private member objects internally. [ In this example, ClassGame would call a method that belongs to ClassEngine, and ClassEngine would ‘secretly’ pass that request on to it’s ClassRenderer subsystem by calling one of its methods. ] Kind of a ‘daisy chain’ of function calls. This makes sense to me, but it seems like it may be slower than some alternative options.

  2. Another way that I’ve seen in other people’s code is have an accessor method that returns a reference or pointer to the location of a particular subsystem. [ So, ClassGame would call a simple method in ClassEngine that would return a reference/pointer to the object that makes up its ClassRenderer subsystem ]. This route seems convenient to me, but it also seems to eliminate the point of having a private member act as a sub-component of a bigger class. Of course, this also means writing much fewer ‘mindless’ functions that simply pass a particular task on, due to the fact that you can simply write one getter function for each independent subsystem.

Considering the various important aspects of OO design (abstraction, encapsulation, modularity, usability, extensibility, etc.) while also considering speed and performance, is it better to use the first or the second type of method for delegating tasks to a sub-component?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There are many ways to do what you want, and it really depends on the context (for example, how big the project is, how much you expect to reuse from it in other projects etc.)

    You have three classes: Game, Engine and Renderer. Both of your solutions make the Game commit to the Engine’s interface. The second solution also makes the Game commit to the Renderer’s interface. Clearly, the more interfaces you use, the more you have to change if the interfaces change.

    How about a third option: The Game knows what it needs in terms of rendering, so you can create an abstract class that describes those requirements. That would be the only interface that the Game commits to. Let’s call this interface AbstractGameRenderer.

    To tie this into the rest of the system, again there are many ways. One option would be:
    1. Implement this abstract interface using your existing Renderer class. So we have a class GameRenderer that uses Renderer and implements the AbstractGameRenderer interface.
    2. The Engine creates both the Game object and the GameRenderer object.
    3. The Engine passes the GameRenderer object to the Game object (using a pointer to AbstractGameRenderer).

    The result: The Game can use a renderer that does what it wants. It doesn’t know where it comes from, how it renders, who owns it – nothing. The GameRenderer is a specific implementation, but other implementations (using other renderers) could be written later. The Engine “knows everything” (but that may be acceptable).

    Later, you want to take your Game’s logic and use it as a mini-game in another game. All you need to do is create the appropriate GameRenderer (implementing AbstractGameRenderer) and pass it to the Game object. The Game object does not care that it’s a different game, a different Engine and a different Renderer – it doesn’t even know.

    The point is that there are many solutions to design problems. This suggestion may not be appropriate or acceptable, or maybe it’s exactly what you need. The principles I try to follow are:
    1. Try not to commit to interfaces you can’t control (you’ll have to change if they change)
    2. Try to prevent now the pain that will come later

    In my example, the assumption is that it’s less painful to change GameRenderer if Renderer changes, than it is to change a large component such as Game. But it’s better to stick to principles (and minimise pain) rather than follow patterns blindly.

    • 0