Why you should never ever ever have Managers in your class name

Re:Why you should never ever ever have Managers in your clas... by azov on Sunday March 31, 2013 @09:09PM (#5470911)

ThingManager is indeed a bad name, but I think the article is blurring the explanation with poorly chosen example. The example is more about wrong design than wrong name, there are certainly legitimate cases when you want a class that deals with multiple things.

ThingManager is a bad metaphor for a class that follows single responsibility principle (http://en.wikipedia.org/wiki/Single_responsibility_principle). It encourages you to stuff too much into a class because managers do many things, and it's not always clear what exactly they do - almost anything can be thought of as some sort of "management". The real reason is mentioned two paragraphs from the end - the name is simply too ambiguous.

[ Parent | on HN ]

Re:Why you should never ever ever have Managers in your clas... by unclebucknasty on Sunday March 31, 2013 @10:46PM (#5471163)

I think there are times when you want a class to do multiple related things and encapsulating them in one place makes sense. And sometimes, the word "manager" is perfectly descriptive and sufficient.

Take the DriverManager class from the JDK (JDBC). To me, it's always been a clean way to register JDBC drivers, get connections, etc. It is responsible for internally managing available driver classes and selecting the appropriate driver to use for a particular connection string. It manages all of this internally, and, from my perspective, it is well-named.

I do think, like anything, the concept can be overused. But, I just don't agree with this kind of "never, ever use x in your class names or your code is evil" blanket statement.

[ Parent | on HN ]