What we should use instead of a “manager” class in a good OOP design?

You almost said it already:

This class gets several responsibilities

(original emphasis).

This violates the Single Responsibility Principle. Additionally, the word Manager suggest an object that manages other objects, which is at odds with the object-oriented principle that objects should encapsulate both data and behavior. This quickly leads to the Feature Envy code smell.

Dividing the manager into many smaller classes is the correct thing to do. To keep them manageable, you can implement a Facade over them.

Leave a Comment