I have a question about design patterns. My project is starting to get bigger and bigger and I feel like my design pattern is inaccurate/imprecise in terms of maintainability, scalability, and readability. The way my project is currently structured is that I have a MainLoopFile where I poll my events, I handle the events, draw the textures, and most importantly, instanciate external classes such as MyClassA up to some arbitrary MyClassZ.

The issue is that I'm making only one instance of each of MyClassX, just so that I can access their member functions fooA(), fooB() using MyClassX x; x.fooA(); from with the main loop file.

Is this the best approach to do this? I feel like

1. Write a class
2. Make a instance of the class
3. Call the functions of that class

methodology is useful whenever one needs to make multiple instances of that class. In my case, I'm only making one. Here is an example

MyClassA.hpp

MyClassA { 
    fooA();
    fooB();
};

MyClassB.hpp

MyClassB { 
    fooA();
    fooB();
};

...

MyClassZ.hpp

MyClassZ { 
    fooA();
    fooB();
};

MainLoopFile.cpp

#include "MyClassA.hpp"
#include "MyClassB.hpp"
...
#include "MyClassZ.hpp"

MainLoopFile { 
    MyClassA a;
    MyClassB b;
    ...
    MyClassZ z;

    while() {
        Event event;
        // do operations on a,b,...,z
    }
}

Is this design pattern correct? Is there anything better?

Things I have considered

• Making namespaces although I don't understand if that is the correct solution
• Making some of the classes static (since only one instance necessary), but then half of my project's content becomes static, and it just feels odd
• Read online about some design patterns, but was not able to find an answer to this specific solution

CodePudding user response：

The model you describe is called a 'singleton' and its a common design pattern. The debate as to whether 'raw code' not in any class , singleton or static methods of a class is a long running lively one.

A singleton is better if some point you might need 2. Now you simply have to create another one. If its all static you have a lot of rewriting to do.

The thing that encapsulates the start up logic 'MainFile' in your case clearly is best static, since you are only running one program.

Things that encapsulate objects that you operate on are probably best as singletons.

Advantage of statics is that they are always there, you dont have to hand pointer / references around. You can just say Froodle::Noodle(widget) and there you are. The down side of that though is its a huge reorg if suddenly you need 2 Froodles

CodePudding user response：

Just so I understand what you're doing -- you're using MyClassA .. Z in order to organize your code. That seems reasonable. But you don't actually have data associated with them.

The two most obvious answers, if I understand your problem correctly, could be:

• Use namespaces and free functions within the namespaces
• Use static methods so at least you're not instantiating empty objects

For the latter, you could then just call MyClassA::foo(); without having an instance of MyClassA.

CodePudding user response：

To ask a design question, the most important part is that "what you want to achieve and what's the limitation" instead of "what you've done" (unless you're facing a legacy codebase, then current architecture is the limitation).

Please explain the context what class A ~ Z does.

• Are they holding states or just having the same function names?
• Why do you need so many different flavors of the same function name?

You may combine multiple patterns to achieve what you want to do.

By your sample code, I presume you want an event loop system.

• You may have multiple event handler instances. Making them Singleton might be what you want, but I don't suggest to make them singleton if your instances have dependency on other instances

• To handle event, I think Observer Pattern is too big for this case. I'd suggest to use Strategy Pattern here since you might want to use different handlers according to different event types.