So indeed Singleton feels odd at many places, see here as a point to begin reading about it. But then considerable arguments are also made in reply. Perhaps in short, the bottom line is brought here, i.e. that Singleton is a good idea only if you have a single shared resource that should be managed. So if the resource in question has to have no more that one instance representation, and this instance is to be responsible for managing this resource, then Singleton is probably the way to go.
Now, your Parameters
and Consts
classes does not seem (in lack of additional info) like they need to be managed. Moreover, using Singleton just so you can access its interface globally in the system is not a good idea. That's because you very quickly loose track of where in the system its being relied upon (what parts depend on it), and so any future changes to it will potentially cause hard-to-anticipate bugs and artifacts.
Is there any reason not to make just a single instance of Consts
and then pass it around to whomever needs it -- thus exposing the dependency instead of hiding it?
For example, foo()
could be defined like this:
void foo(const Consts& consts) {
Matrix a = consts._k;
int b = consts._params.x;
}
Or your OtherClass
class could receive it in its CTor and store it as a member for its methods to access:
class OtherClass {
private:
const Consts& mConsts;
public:
OtherClass(const Consts& consts)
: mConsts(consts)
{}
void foo() {
Matrix a = mConsts._k;
int b = mConsts._params.x;
}
}