0

Please excuse me if my question is already answered but i searched both SO & Software Engineering and did not find a straight answer or bits of information that make this clear.

I'm developing an kind-of-small application which in short, connects to a web service, fetches some data and plays back some music based on the fetched data. I have broken down all the parts of my application as different "module interfaces", for example a "WebServiceInterface", "ConfigurationInterface", "SystemTrayInterface" etc. I'm in the beginning steps of understanding & implementing SRP(and generally SOLID) in my application.

Now, all these interfaces & their implementations are broken on separate headers/sources. So a short version of my question is: "In respect to SRP, where should i declare & instantiate the necessary "modules" required for the application startup and use them?"

I mean, there must be a place(main(), a function or a class) where some of the classes are declared and initialized to a proper state in order for the application to actually launch. My problem stems from the fact that SRP states:

Every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class

But I'm confused, if cannot have a single place which contains all the declarations & instantiations of my main modules, how I'm supposed to start the application?

I saw this: https://stackoverflow.com/a/5744241/1044356

Loose coupling between 2 classes means each class has very few knowledge of the internal behavior of the other class. You may have a higher degree of "coupling" between classes which belong to the same "module" or "package", and it's not a bad practice

Does this mean i can have a class which wraps around interfaces to modules that are independent with each other and set them up? This sounds like a GOD class to me.

I can provide additional information if needed to clear any ambiguities.

Dimitris
  • 38
  • 5

1 Answers1

0

Encapsulation is about hiding internal implementation details. the application object doesn't need to know how the web service object retrieves data, only that if it (the application) makes a properly formatted request and nothing else goes wrong that it will get data in return. It does not mean that the application can't instantiate a web service if it needs to make such a request.

Some idioms (such as pimpl) allow you to hide nearly all the implementation details by having a public interface that defers to a private implementation. Using such an idiom your application woud know only about the wrapper and not even be able to see the data needed to make the private object work.

This can be taken to an extreme where the only free-standing object (meaning an object not part of or at least owned by another) is the application object itself.

SoronelHaetir
  • 14,104
  • 1
  • 12
  • 23
  • Actually this level of extremeness i had in mind :) So, in my main.cpp, where the "application object" resides, i could include all the interface headers, declare the object pointers as global variables, then have a series of functions like init_systemX and init_systemY, configX, configY etc. all called from main(), each having the responsibility to instantiate, set callbacks and/or load configurations of their modules. Do i get it right? – Dimitris Dec 03 '17 at 22:16