10

I'm prone to building centralized classes that manage the other classes in my designs. It doesn't store everything itself, but most data requests would go to the "manager" first. While looking at an answer to this question I noticed the term "God Object". Wikipedia lists it as an antipattern, understandably.

Where is the line between a legitimate glue class, or module, that passes data and messages from place to place, and a class that is doing too much?

Community
  • 1
jprete
  • 1,509
  • 11
  • 16

1 Answers1

15

A lot of people say things like "a class should never be bigger than your head".

However, I've just participated in a discussion with some really great, world-class programmers on this very subject. I've talked it through with one of the Naked Objects guys. As far as we can tell, sometimes, this happens, and there's not much way of getting around it.

Normally, though, the one class to which this happens is a domain object which represents the fundamental element of your domain - an Account for banking, a Sale for retail, etc. If you're finding it happens to other classes too, you probably want to consider the responsibility of that class. Here are my tips:

  • If it's called "Manager", "Helper" or "Service", chances are it's too big. Once you actually work out what the responsibility of a class ought to be, you'll find it easier to delegate the other responsibilities.
  • If it's called "Controller", it should be responsible for controlling the interaction between a bunch of other classes... and nothing else.
  • If it's passing data and messages between different physical nodes then either it should deal with converting a specific message to a serialized form, or it handles the transfer mechanism. For instance, you might have one class which converts a Bank Transaction to XML, and another class which sends that XML over HTTP.
  • If it's passing events between different modules in an application, then it should be responsible for telling listeners when an event is raised, and nothing else.

As a rule of thumb, if it's too big, see if you can delegate any responsibilities to another class, and if you can't, it's probably OK.

Lunivore
  • 4,232
  • 1
  • 18
  • 23
  • Good answer with useful concrete guidelines. I tend to create classes like this for domain objects where all, or almost all, the data represents some aspect of the domain and I want to be able to treat it as a unit. Then I tend to delegate the actual responsibilities to classes that are only really instantiated inside of the big class. So I'm pretty close to the line, and I should probably lean towards making the individual classes smaller when I write it. – jprete Mar 21 '11 at 16:34