How do I avoid this singleton-like design pattern? - c++

Question

We have a rendering pipeline and our current code creates an instance for every stage of the pipeline. This means that as we update our code, we will be constantly updating the pipeline (or multiple sets of pipelines) code. This feels like a point where we should have additional abstraction, but we're not sure how to proceed.
Edit: It seems my pseudo code is not well understood. Perhaps a diagram will more easily explain the pattern.
Link to a block diagram: http://yuml.me/0650d1bf.svg
// yuml.me
[GenericRenderStage|render|Parent Class]<---[Shadow1RenderStage|render|Derived Class]
[Shadow1RenderStage|render|Derived Class]<---[_shadowRenderStage1|Singleton Object]
[GenericRenderStage|render|Parent Class]<---[Shadow2RenderStage|render|Derived Class]
[Shadow2RenderStage|render|Derived Class]<---[_shadowRenderStage2|Singleton Object]
[GenericRenderStage|render|Parent Class]<---[ShadowNRenderStage|render|Derived Class]
[ShadowNRenderStage|render|Derived Class]<---[_shadowRenderStageN|Singleton Object]
Psuedo-c++ code of parent class:
class GenericRenderStage(...) {
/// Render method
virtual void render(void) {
/// handles drawing code
}
class Shadow1RenderStage : GenericRenderStage(...) {
/// Render method
void render(void) {
/// handles custom drawing for shadow1 stage
}
class Shadow2RenderStage : GenericRenderStage(...) {
/// Render method
void render(void) {
/// handles custom drawing for shadow2 stage
}
...
class ShadowNRenderStage : GenericRenderStage(...) {
/// Render method
void render(void) {
/// handles custom drawing for shadowN stage
}
We then have a set of the same type of pattern for our pipelines...
class GenericRenderPipeLine(...) {
/// Render method
virtual void render(void) {
/// handles drawing code
}
class ShadowRenderPipeline : GenericRenderPipeLine() {
/// instantiate stages for this pipeline
ShadowRenderPipeline() {
shadow1Stage = new Shadow1RenderStage();
shadow2Stage = new Shadow2RenderStage();
...
shadowNStage = new ShadowNRenderStage();
}
/// Render method
void render(void) {
/// setup fbo
/// for each render stage, render
shadow1Stage.render()
shadow2Stage.render()
...
shadowNStage.render()
/// handle fbo
}
Something here seems really wrong with the pattern. We've got a parent class that is basically a set of virtual methods to be inherited by a customized class that only ever has one instance.

Answer 1

From what I understand (please correct me if I'm wrong), each render stage is unique and doesn't really follow any specific pattern. So, I think it's best to keep those the way they are; have each render stage in a self-contained file/class.
However, I think you could reduce a lot of work by eliminating your render pipeline inheritance structure. All of these appear to be the same (i.e. they have some number of stages and call render() on each of them). What if you instead had a dynamic, generic pipeline?
#include <vector>
#include <memory>
class DynamicRenderPipeline {
private:
std::vector<std::unique_ptr<GenericRenderStage>> renderStages;
public:
void add(std::unique_ptr<GenericRenderStage> renderStage) {
renderStages.push_back(std::move(renderStage));
}
void render() {
for (auto& stage : renderStages) {
stage->render();
}
}
};
int main() {
DynamicRenderPipeline pipeline;
pipeline.add(std::unique_ptr<GenericRenderStage>(new RenderStage1()));
pipeline.add(std::unique_ptr<GenericRenderStage>(new RenderStage2()));
pipeline.add(std::unique_ptr<GenericRenderStage>(new RenderStage3()));
pipeline.add(std::unique_ptr<GenericRenderStage>(new RenderStage4()));
pipeline.add(std::unique_ptr<GenericRenderStage>(new RenderStage5()));
pipeline.render();
}
You can now just create instances of DynamicRenderPipeline and add any stages you wish. When you call render() on it, it will loop through all of the added render stages in the proper order. Now your pipeline only depends on the GenericRenderStage interface. If you're not using C++11 you could do the same with raw pointers (instead of unique_ptr), but you'd have to make sure to clean up your vector in the pipeline's destructor.

Answer 2

The fact that you only ever instantiate one object of each one of the many classes you created is a manifestation of a common problem in class-based OOP à la Java/C++. It is somewhat easier to circumvent in C++ than in Java.
The problem is simply that all code has to reside in class definitions if you want to go the pure class-based OO way. For instance, in Java, if you wanted to create many vastly different comparators (boolean predicates of two values of the same type), you ideally would have to create just as many subclasses of the standard Java generic interface Comparator. Actually, I lied, because in many cases you could just use the
new Comparator<Type>() {
public bool compare(Type a, Type b) { /* */ }
}
syntax, which is the closest Java ever got to having first-class citizen functions prior to Java 8. However, even that syntax doesn't work when you want to allow the creation of customized comparators, and you then have to write an entire class like so in order to void repeating yourself:
class CompareIntsPlusX implements Comparator<int>
{
private int number;
public CompareIntsPlusX(int number) {
this.number = number;
}
public bool compare(int x, int y) {
return x < y + number;
}
}
Comparator<int> myComparator = new CompareIntsPlusX(3);
and we end up with very cumbersome syntax for even the simplest of objects. Notice that in any (somewhat) functional programming language like Javascript, this problem would be more easily solved.
The same phenomenon is happening here. You have been going the class-based OO way in your pipeline stage definitions, and now you realise it's not scalable because you only need one object carrying with it the code defined in its class, and you need many such objects.
Those objects are what you referred to as "singletons" even though they do not in any way follow the Singleton design pattern. They are de facto singletons, and the reason for this is that they are actually just functions in disguise. Their only goal is to "carry" with them a void render() method.
From here you have several solutions:
If the render functions are vastly different, and you cannot generate them from one class that accepts parameters like we did with the CompareIntsPlusX Java class above, that is to say if you cannot factor your code, then
If you are using a functional style of C++03 (I wouldn't recommend that) or of C++11 (I have never used what I'm about to suggest) then you can simply use one RenderStage class defined like so:
class RenderStage
{
private:
std::function<void()> renderFunction;
public:
RenderStage(std::function<void()> renderFunction)
: renderFunction(renderFunction)
{ }
void render() {
renderFunction();
}
}
/* Somewhere else in the code, create your render stages */
RenderStage r1([]() {
// blah blah
});
// You can also capture stuff!
Texture tex;
RenderStage r2([&tex]() {
// blah blah
});
In C++03, we would use function pointers (whose functions are defined in a namespace because we don't want to be polluting the global namespace). Note that in the C++11 case, we only need to use std::function if captures are needed in the lambdas. If not, then just use function pointers.
Else, if you want to keep using an OO style, then create as many classes as you need and don't feel bad about it. In fact, creating anonymous classes is what the compiler does behind your back when you create lambdas (in fact it creates classes if your lambdas have captures and simple functions if not) and the Java compiler does it too when you "instantiate an interface".
Else, if the render methods can be factored, i.e. if instead of N classes you can have one with a constructor that allows for customization, then do that instead.
It's probable that a mix of the first and second solutions is what you need. You should try the second solution of having customizable render stage objects before you go for the more complex solution.