I regularly come across some weird classes that smell already purely on their poor naming.
A few of them end with “Manager” (e. g. BankAccountManager, ReservationManager or ServiceManager, urgs). Why is that bad? Imagine a manager as a real person that manages something. What does he actually do while managing something? He doesn’t manage people for instance. He instructs them with new tasks, advices or praises them. “Manage” is just an abstraction of a real activity. The real activity is the act of taking a concrete action.
How can a class that’s named “Manager” then can do anything concrete when it is an abstraction? Nothing and therefore all: A BankAccountManager opens new bank accounts, loads information about existing ones, changes some data of accounts and so on. So “manage” as a generic term decays into activities like “open”, “load”, “change” etc. . And that is the core problem: All of these activities are sufficiently complex and worth creating separate classes. If you put them all under one umbrella, you’ll get a great mess with unclear responsibilities among the different code parts. Low Cohesion because there isn’t really a relationship between them to profit from and strong coupling where there shouldn’t be one: A pure anti-pattern!
If you use “Manager” as a part of you class name, there is always one big smell in sight: The violation of the Single Responsibility Principle! So split up your “Manager” classes into separated ones. It’s always a good starting point for sensible refactoring activities.
Front page picture: Business photograph designed by Katemangostar – Freepik.com