Revisiting The Purpose of Manager Classes

I came across a debate about whether naming a class [Something]Manager is proper. Mainly, I came across this article, but also found other references here and here. I already had my own thoughts on this topic and decided I would share them with you.

I started thinking on this a while ago when working in a Swing-powered desktop app. We decided we would make use of the Listeners model that Swing establishes for its components. To register a listener in a Swing component you say:

// Some-Type = {Action, Key, Mouse, Focus, ...}
component.add[Some-Type]Listener(listener); 

That's not a problem until you need to dynamically remove those listeners, or override them (remove and add a new listener that listens to the same event but fires a different action), or do any other 'unnatural' thing with them. This turns out to be a little difficult if you use the interface Swing provides out-of-the-box. For instance, to remove a listener, you need to pass the whole instance you want to remove; you would have to hold the reference to the listener if you intend to remove it some time later.

So I decided I would take a step further and try to abstract the mess by creating a Manager class. What you could do with this class was something like this:

EventsListenersManager.registerListener(
        "some unique name", component, listener);
EventsListenersManager.overrideListener("some unique name", newListener);
EventsListenerManager.disableListener("some unique name");
EventsListenerManager.enableListener("some unique name");
EventsListenerManager.unregisterListener("some unique name");

What we gained here??? We got rid of the explicit specification of [Some-Type] and have a single function for every type of listener; and we defined a unique name for the binding, which will be used as an id to remove, enable/disable, and override listeners; a.k.a. no need to hold references.

Obviously, it is now convenient to always use the manager’s interface, since it reduces the need to trick our code and gives us a simple and more readable interface to achieve many things with listeners. But that’s not the only advantage of this manager class.

You see, manager classes in general have one big advantage: they create an abstraction of a service and work as a centralized point to add logic of any nature, like security logic or performance logic. In the case of our EventsListenersManager, we put some extra logic to enchance the way we can use listeners by providing an interface that simplifies their use: it is easier to make a switch between two listeners now than it was before. Another thing we could have done was to restrict the number of listeners registered in one component for performance sake (Hint: listeners execution don’t run in parallel).

So manager classes seem to be a good thing, but we can’t make a manager for every object we want to control in an application. This would consume time and would make us start thinking in a manager class even when we don’t need it. But we can discover a pattern for the need of defining a manager. I’ve seen them used when the resources they control are expensive, like database connections, media resources, hardware resources, etc; and as I see it, expensiveness can come in many flavors:

• Listeners are expensive because they may be difficult to play with and can be a bottleneck in performance (we must keep them short and fast).
  
• Connections are expensive to construct.
  
• Media resources are expensive to load.
  
• Hardware resources are expensive because they are scarce.
  

So we create different managers for them:

• We create a manager for listeners to ease and control their use.
  
• We create a connections pool in order to limit and control the number of connections to a database.
  
• Games developers create a resources manager to have a single point to access resources and reduce the possibility to load them multiple times.
  
• We all know there is a driver for every piece of hardware. That’s their manager.