What is a better name than Manager, Processor etc?

Question

I am reading the book Clean Code http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

The author mentions that you should avoid words like Manager, Processor, Data or Info in the name of the class. I have used these everywhere. What are some better names? I have a class that is responsible for starting and stopping connections. So I named it ConnectionManager.

Solution 1

Wait!

The point of the book is, that Manager in the classname means the class does more than one thing. Robert C. Martin refers in this section to the Single Responsibility Principle!

This is not about the name, its about the classes which are usually named like this. Changing the name won't reduce the responsibilities of a class!

Solution 2

My guess is the book makes this point because it's trying to encourage you to choose a more descriptive name for your class. There's no "naming convention" to follow here; that's the problem you fell into in the first place. Any universal naming convention won't be able to consider the specific class and choose the best name for it. Expressivity is more important than following a naming convention. Calling a class a "Manager" or a "Processor" doesn't say very much about it and what it does to a person who is reading your code for the first time.

If you really can't think of anything better, there's nothing inherently wrong with naming a class ConnectionManager. But I'd at least name it after the type of collections that it manages. Or maybe how it manages those collections. Or why it manages those collections.

Also consider that following "one-size-fits-all" rules rarely helped anyone to write better code (at least, not better in the sense of "more understandable" or "more expressive). I tend to postfix the names of all my native wrapper classes with Manager. For example, I might have classes called DwmManager, or VisualStylesManager. In that very specific case, it does mean something to me. If I see a class named Manager in my code base, I know it wraps a bunch of closely-related functionality. You have to make the decision on a case-by-case basis, understanding what you're ultimately trying to accomplish.

If you read Code Complete and missed the part about writing code that's clear and understandable (and therefore maintainable), you might have missed the point.

Solution 3

In the example of your ConnectionManager class, it is possible that the class is more indicative of a design flaw which necessitates a "bad" name. Is the class doing something besides performing actions that could just as easily be done in a singleton subclass called MyDatabaseConnection?

Solution 4

Take for instance name DataProcessor.

First it is true that each function works with data, takes data or return some data unless is

void f(void)

But if it is such type of function it absolutely makes something so it is Processor in any case.

DataProcessor is basically anything because it does no say what it manipulates and how. So you should replace

DataProcessor with UserInfoStore for instance.

Solution 5

OH, NO !!

Please don't be intimidated by general pronouncements about how you "should" name things. They are your things, after all. Maybe your name "Manager" is better than "Connection Manager" because it's shorter. Especially so if that section of your code mainly manages "connections" and little else.

I believe that such books have very useful ideas, but only for coders who will never read them. Why? Because engineers who do read such books have already internalized and incorporated the soundest of the principles in them. And coders who won't read them don't care.

View more solutions

Comments

[Wade Tandy]

Does it give a specific reason for this?

[Pascal Cuoq]

I think the reason to avoid "Manager" is that it doesn't say anything specific. If there was an universal replacement, the replacement would be just as bad for exactly the same reasons.

[David Hall]

possible duplicate of Naming Classes - How to avoid calling everything a "<WhatEver>Manager"?

[Steve Jessop]

Off the top of my head, would your ConnectionManager be better as a ConnectionFactory or just Connector? Even if connections can't stop themselves (for instance with a close() method), it's not a total outrage for creation and destruction to be linked, so you're not really hiding anything if you highlight that creating connections is the main thing you do (hence use that as the name), and stopping them is the natural consequence...

[Steve Jessop]

... The trouble with Manager is that it doesn't tell us that your class starts or stops connections, or what else (if anything) it does with them. For all we know from the name it just bosses them around a bit and takes the credit for everything they achieve.

[Arnis Lapsa]

Some more of my favorites along these lines - Helper, Common, Core, Utilities

[Arnis Lapsa]

Naming is one of the most important things in software development

[Cody Gray]

@Arnis: I feel like that statement goes a bit too far in the other direction. Although I agree that naming (insofar as it helps you to write clear, understandable code) is important and not to be underestimated.

[Arnis Lapsa]

@Cody it surely is. Without naming, You are absolutely unable to create natural abstractions. Without abstractions You end up with procedural code (think 20k lines in a "class").

[uriDium]

I used the word connection but it is to another machine not a database. The ConnectionManager starts and stops those connections.

[Wade Tandy]

I'm saying is it might be better to get rid of ConnectionManager and instead subclass Connection as something like ComputerConnection. This class can handle its own lifecycle, so you won't need a cumbersome Manager class.

[Alex 75]

Probably I'll return to use "*Manager" at least for the CRUD (extended) operations, because they really "manage" the specific item. For specific actions like search and grouping for analisys I already started to create *Analisys and *Provider classes.

[xstmpx]

Single Responsibility Principle doesn't mean that class should do just one thing. Actually first thing the author says in chapter 7: SRP of his book Clean Architecture is that SRP doesn't mean that class should do just one thing. SRP means that "A module should have one, and only one, reason to change".

[krozaine]

This could help someone : I have started to think on naming it Operators. Like AccountOperator which essentially is responsible to operate on certain things. This is not as vague as Manager and not very concrete also. Manager classes can have operator classes to rely for operations OR a Mediator class to delegate some of its lower level implementation responsibilities, depending upon the situation and size of the problem

[Chaks]

Doesn't doing more than one thing be more reasons to change the module, a little confused here. Although I do think that there is essentially no need for a Book Manager and call it rather a "BookLibrary".