I asked a similar question, but where possible I try to copy the names already in the .NET framework, and I look for ideas in the Java and Android frameworks.

It seems Helper, Manager, and Util are the unavoidable nouns you attach for coordinating classes that contain no state and are generally procedural and static. An alternative is Coordinator.

You could get particularly purple prosey with the names and go for things like Minder, Overseer, Supervisor, Administrator, and Master, but as I said I prefer keeping it like the framework names you re used to.

Some other common suffixes (if that is the correct term) you also find in the .NET framework are:

• Builder
  A type that use some parameters to construct an instance of a special type. Builder is usually a throwaway. It may not even need to allocate a variable.
  If the type needs to repeatedly create objects, please use Factory.
  if the type responsible for create multiple different type objects, please use Factories.
• Writer
  Write some variable into something.
• Reader
  Read something as variable.
• Handler
  Designed to deal with a situation or something.
• Container
  Can put something into it.

You can take a look at source-code-wordle.de, I have analyzed there the most frequently used suffixes of class names of the .NET framework and some other libraries.

The top 20 are:

• attribute
• type
• helper
• collection
• converter
• handler
• info
• provider
• exception
• service
• element
• manager
• node
• option
• factory
• context
• item
• designer
• base
• editor

I m all for good names, and I often write about the importance of taking great care when choosing names for things. For this very same reason, I am wary of metaphors when naming things. In the original question, "factory" and "synchronizer" look like good names for what they seem to mean. However, "shepherd" and "nanny" are not, because they are based on metaphors. A class in your code can t be literally a nanny; you call it a nanny because it looks after some other things very much like a real-life nanny looks after babies or kids. That s OK in informal speech, but not OK (in my opinion) for naming classes in code that will have to be maintained by who knows whom who knows when.

Why? Because metaphors are culture dependent and often individual dependent as well. To you, naming a class "nanny" can be very clear, but maybe it s not that clear to somebody else. We shouldn t rely on that, unless you re writing code that is only for personal use.

In any case, convention can make or break a metaphor. The use of "factory" itself is based on a metaphor, but one that has been around for quite a while and is currently fairly well known in the programming world, so I would say it s safe to use. However, "nanny" and "shepherd" are unacceptable.

We could do without any xxxFactory, xxxManager or xxxRepository classes if we modeled the real world correctly:

Universe.Instance.Galaxies["Milky Way"].SolarSystems["Sol"]
        .Planets["Earth"].Inhabitants.OfType<Human>().WorkingFor["Initech, USA"]
        .OfType<User>().CreateNew("John Doe");

;-)

It sounds like a slippery slope to something that d be posted on thedailywtf.com, "ManagerOfPeopleWhoHaveMortgages", etc.

I suppose it s right that one monolithic Manager class is not good design, but using Manager is not bad. Instead of UserManager we might break it down to UserAccountManager, UserProfileManager, UserSecurityManager, etc.

Manager is a good word because it clearly shows a class is not representing a real-world thing . AccountsClerk - how am I supposed to tell if that s a class which manages user data, or represents someone who is an Accounts Clerk for their job?

When I find myself thinking about using Manager or Helper in a class name, I consider it a code smell that means I haven t found the right abstraction yet and/or I m violating the single responsibility principle, so refactoring and putting more effort into design often makes naming much easier.

But even well-designed classes don t (always) name themselves, and your choices partly depend on whether you re creating business model classes or technical infrastructure classes.

Business model classes can be hard, because they re different for every domain. There are some terms I use a lot, like Policy for strategy classes within a domain (e.g., LateRentalPolicy), but these usually flow from trying to create a "ubiquitous language" that you can share with business users, designing and naming classes so they model real-world ideas, objects, actions, and events.

Technical infrastructure classes are a bit easier, because they describe domains we know really well. I prefer to incorporate design pattern names into the class names, like InsertUserCommand, CustomerRepository, or SapAdapter. I understand the concern about communicating implementation instead of intent, but design patterns marry these two aspects of class design - at least when you re dealing with infrastructure, where you want the implementation design to be transparent even while you re hiding the details.

Being au fait with patterns as defined by (say) the GOF book, and naming objects after these gets me a long way in naming classes, organising them and communicating intent. Most people will understand this nomenclature (or at least a major part of it).

If I cannot come up with a more concrete name for my class than XyzManager this would be a point for me to reconsider whether this is really functionality that belongs together in a class, i.e. an architectural code smell .

I think the most important thing to keep in mind is: is the name descriptive enough? Can you tell by looking at the name what the Class is supposed to do? Using words like "Manager", "Service" or "Handler" in your class names can be considered too generic, but since a lot of programmers use them it also helps understanding what the class is for.

I myself have been using the facade-pattern a lot (at least, I think that s what it is called). I could have a User class that describes just one user, and a Users class that keeps track of my "collection of users". I don t call the class a UserManager because I don t like managers in real-life and I don t want to be reminded of them :) Simply using the plural form helps me understand what the class does.

Specific to C#, I found "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries" to have lots of good information on the logic of naming.

As far as finding those more specific words though, I often use a thesaurus and jump through related words to try and find a good one. I try not to spend to much time with it though, as I progress through development I come up with better names, or sometimes realize that SuchAndSuchManager should really be broken up into multiple classes, and then the name of that deprecated class becomes a non-issue.

I believe the critical thing here is to be consistent within the sphere of your code s visibility, i.e. as long as everyone who needs to look at/work on your code understands your naming convention then that should be fine, even if you decide to call them CompanyThingamabob and UserDoohickey . The first stop, if you work for a company, is to see if there is a company convention for naming. If there isn t or you don t work for a company then create your own using terms that make sense to you, pass it around a few trusted colleagues/friends who at least code casually, and incorporate any feedback that makes sense.

Applying someone else s convention, even when it s widely accepted, if it doesn t leap off the page at you is a bit of a mistake in my book. First and foremost I need to understand my code without reference to other documentation but at the same time it needs to be generic enough that it s no incomprehensible to someone else in the same field in the same industry.

I d consider the patterns you are using for your system, the naming conventions / cataloguing / grouping of classes of tends to be defined by the pattern used. Personally, I stick to these naming conventions as they are the most likely way for another person to be able to pick up my code and run with it.

For example UserRecordsClerk might be better explained as extending a generic RecordsClerk interface that both UserRecordsClerk and CompanyRecordsClerk implement and then specialise on, meaning one can look at the methods in the interface to see what the its subclasses do / are generally for.

See a book such as Design Patterns for info, it s an excellent book and might help you clear up where you re aiming to be with your code - if you aren t already using it! ;o)

I reckon so long as your pattern is well chosen and used as far as is appropriate, then pretty uninventive straightforward class names should suffice!