What is the best way to handle glue between different classicly OOP objects at the higher levels of abstraction?

Question

In object oriented programming, it is commonly said that each class/object/instance should have a well-defined purpose. For example, there may be a Window class in a windowing toolkit, a ChunkLoader class in a Minecraft-like game, or a Matrix<> class (template) in a linear algebra library. In each of these cases, the class has a specific job. In these examples the jobs, respectively, are to handle the underlying windowing api and expose useful functions, load and unload chunks, and represent a matrix with useful operations.

While this guideline (single purpose for each class) is good advice in many cases, it seems to fall flat for the glue parts of a program. That is, something needs to call the chunkloader, matrices, or window classes as needed. This can be shuttling data between them, setting them up with the appropriate polymorphic interfaces between them, or a host of other things that combine the aforementioned parts (ChunkLoader, etc.) into a whole. For example, in a Minecraft-like game something needs to handle the main loop and call the other classes with more defined purposes as needed.

While I am working on my programs, my first (and, so far, only) idea is to create classes that abstract larger areas of the program, and that deal with the less abstract classes inside them. This, however, tends to take the form of manager classes, in name or otherwise. For example, there may be a RenderingManager class in a video game that has a data member for each general part of the world (ie. a member to render the world itself, another for other players, and another for GUI). Then, within it, the GuiManager class that has its own members for various parts of the GUI (eg. inventory, health, pause screen).

This recursive manager structure, however, has several problems:

• Managers (whether or not they are called managers) are bad practice in and of themself, according to the research that I have done before asking.
• The manager classes are necessarily a particularly complex part of the program, as they touch many (or all) parts of the program, and thus need to keep in mind the idiosyncrasies of those parts. This can be partially mitigated by having clean interfaces to each layer of abstraction, but not all problems are always amicable to clean interfaces.
• The manager classes are by their very nature hard to unit test, as, at the upper levels, they rely on huge swaths of the rest of the code. This requires essentially a complete program to run unit tests. Using polymorphism as a mitigation is undesirable as the interface to each manager class should completely hide the types with a lower level of abstraction, thus making passing pointers to other types impractical. Additionally, in languages such as C++, polymorphism isn't available with basic members, meaning that the already-complex manager classes get more complex in order to enable unit tests.
• This hierarchy of manager classes can be represented by a tree where each node is an instance, with a main manager as the root and the sub-managers as its children, and so on down to the most basic classes. Sometimes, it is necessary for a node to communicate with its cousin (eg. for the renderer to query the physics engine in a video game). There is no clear way to handle this in this design.

Is there some better technique for the large-scale organization of a program and/or to glue together the more basic OOP parts? If so, what is it? If not, how can I mitigate the aforementioned problems?

Answer 1

Manager classes are born out of wrong abstractions, therefore any solution based on them is bound to not fit well and cause all sorts of problems, especially with OO concepts.

Let me just mention one example that I encountered this week. I was writing "subscription" handling in an Android application. Now "normally" you would see some SubscriptionManager that will give you a Subscription, that would probably contain some product id, whether it is paid, stuff like that. That is the generic abstraction of what a subscription is (some would argue).

However, what I wrote was just one Subscription class that contained a single method Content retrieveContent() (roughly).

Instead of generalizing what a "subscription" is to basically any application, I've made my own Subscription that is just a subscription in my application. I didn't have to solve subscription management for all applications, just for mine. This also means, that business concepts can be part of what my Subscription is. And in my domain a subscription's only purpose is to access some content.

This is actually true for all objects. All objects (in the application) should have some amount of business logic in them, otherwise why would you have them in the first place? All other objects (like String, Matrix, Window, etc) should have absolutely nothing to do with the application and should preferably come from libraries.

At the end I don't have things that need to be "glued" together, rather things will naturally contain each other or refer to each other along the lines of business logic (like a Subscription will retrieve a Content, instead having ContentManager.retriveByProductId() or some such).

Word of caution: Most projects (that I saw in the last 20 years) just do "Managers" and are content with mostly procedural decomposition, so you probably would be swimming against the tide trying to do something more inline with OO.

Answer 2

Although I agree that managers (especially when there are a few of them...) becomes problematic, I don't think that there is any good workaround - they are necessary, and this is the reason we have patterns like Mediators or Facades. Their sole reason of existence is to "glue together" other parts of a program. In this sense, if a class's sole responsibility is to glue together other classes, than it should still be SOLID. At least for the "S" part...

Writing tests for such a class would be closer to integration testing than to unit testing, and will definitely require sound unit tests for the classes it glues together. If you want a unit test - then you would mock quite a few things around, if you have the time and patience.

Now, things can become bloated easily if the "manager" class starts to hold a state of its own that is used by the classes it combines (which is, different from the references to these classes). In such cases probably the best thing (if possible) is to split the "manager" class into two pieces - one holds the references to classes that need to be combined (the "manager" / mediator part) and the other - the state (read Redux in the React/Angular world). The "gluable" classes would take whatever state they need from the Store and take any instructions they need from the Manager.

If this also doesn't help... the only other thing I can muster is "microservicing" the program. Which is, split it into logically independent parts and leave any interactions between them to a suitable protocol. This way you will at least save yourself from the need of too many managers, at the price of reduced performance (assuming that interacting via HTTP, say, is slower than whatever interactions are currently implemented). The benefit is reduced complexity - instead of one giant program you have a few smaller and independent of each other.