What is a better name than Manager, Processor etc?

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.

回答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?

回答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.

回答5:

I tend to use the word "Initialize" or "Initializer" quite frequently. If it's anything else, I usually think of a synonym that is really long compared to the first thing I thought of. I also use the term "Parser" and other things.

回答6:

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.

回答7:

"Helper", "Common", "Core", "Utilities" seems equal or worst than "Manager". Them don't say nothing about what they do.
"Factory" is absolutely wrong here.
Alternative names are "Coordinator" or "Controller".

yous said: I have a class that is responsible for starting and stopping connections. So I named it ConnectionManager.

If the class just "start" and "stop" the connection, why not "ConnectionSwitcher" ?

you said: I have used these everywhere.

I have many *Manager classes too. Today I decided to change the name of "AccountManager". It uses the Account repository to perform CRUD operations.

I splitted it in "AccountSecurity" and "AccountOperations".

Them exists in MyProject.BusinessLogic namespace and both uses AccountRepository class that expose the CRUD methods. The former is responsible for actions like "Login" and "ChangePassword". The latter is responsible for CRUD operations against the database but regulated by some logic, for example if exists some registry records for the Account it cannot be deleted. (The "AccountOperations" uses also other repositories to retrieve needed informations)

I'm not happy with "operations" and I'm searching something better (Coordinator, Supervisor...) but it is a start.

My case would be an example of the way to think at it.

回答8:

dont be too concerned about the name, dont pay much attention to it unless you or someone really dont like it.