title: Naming Classes - How to avoid calling everything a "<WhatEver>Manager"?
body: <p>A long time ago I have read an article (I believe a blog entry) which put me on the "right" track on naming objects: Be very very scrupulous about naming things in your program.</p>
  
  <p>For example if my application was (as a typical business app) handling users, companies and addresses I'd have a <code>User</code>, a <code>Company</code> and an <code>Address</code> domain class - and probably somewhere a <code>UserManager</code>, a <code>CompanyManager</code> and an <code>AddressManager</code> would pop up that handles those things.</p>
  
  <p>So can you tell what those <code>UserManager</code>, <code>CompanyManager</code> and <code>AddressManager</code> do? No, because Manager is a very very generic term that fits to anything you can do with your domain objects.</p>
  
  <p>The article I read recommended using very specific names. If it was a C++ application and the <code>UserManager</code>'s job was allocating and freeing users from the heap it would not manage the users but guard their birth and death. Hmm, maybe we could call this a <code>UserShepherd</code>.</p>
  
  <p>Or maybe the <code>UserManager</code>'s job is to examine each User object's data and sign the data cryptographically. Then we'd have a <code>UserRecordsClerk</code>.</p>
  
  <p>Now that this idea stuck with me I try to apply it. And find this simple idea amazingly hard.</p>
  
  <p>I can describe what the classes do and (as long as I don't slip into quick &amp; dirty coding) the classes I write do exactly <strong>one</strong> thing. What I miss to go from that description to the names is a kind of catalogue of names, a vocabulary that maps the concepts to names.</p>
  
  <p>Ultimately I'd like to have something like a pattern catalogue in my mind (frequently design patterns easily provide the object names, e.g. a <em>factory</em>)</p>
  
  <ul>
  <li>Factory - Creates other objects (naming taken from the design pattern)</li>
  <li>Shepherd - A shepherd handles the lifetime of objects, their creation and shutdown</li>
  <li>Synchronizer - Copies data between two or more objects (or object hierarchies)</li>
  <li><p>Nanny - Helps objects reach "usable" state after creation - for example by wiring to other objects</p></li>
  <li><p>etc etc.</p></li>
  </ul>
  
  <p>So, how do you handle that issue? Do you have a fixed vocabulary, do you invent new names on the fly or do you consider naming things not-so-important or wrong?</p>
  
  <p>P.S.: I'm also interested in links to articles and blogs discussing the issue. As a start, here is the original article that got me thinking about it: <a href="http://www.bright-green.com/blog/2003_02_25/naming_java_classes_without_a.html" rel="noreferrer">Naming Java Classes without a 'Manager'</a></p>
  
  <hr>
  
  <h2>Update: Summary of answers</h2>
  
  <p>Here's a little summary of what I learned from this question in the meantime.</p>
  
  <ul>
  <li>Try not to create new metaphors (Nanny)</li>
  <li>Have a look at what other frameworks do</li>
  </ul>
  
  <p>Further articles/books on this topic:</p>
  
  <ul>
  <li><a href="https://stackoverflow.com/questions/1194403/what-names-do-you-find-yourself-prepending-appending-to-classes-regularly">What names do you find yourself prepending/appending to classes regularly?</a> </li>
  <li><a href="https://stackoverflow.com/questions/38019/whats-the-best-approach-to-naming-classes">What’s the best approach to naming classes?</a></li>
  <li>Book: <a href="https://rads.stackoverflow.com/amzn/click/com/0201633612" rel="noreferrer" rel="nofollow noreferrer">Design Patterns: Elements of Reusable Object-Oriented Software (Hardcover)</a></li>
  <li>Book: <a href="https://rads.stackoverflow.com/amzn/click/com/0321127420" rel="noreferrer" rel="nofollow noreferrer">Patterns of Enterprise Application Architecture (Hardcover)</a></li>
  <li>Book: <a href="https://rads.stackoverflow.com/amzn/click/com/0321413091" rel="noreferrer" rel="nofollow noreferrer">Implementation Patterns (Paperback)</a></li>
  </ul>
  
  <p>And a current list of name prefixes/suffixes I collected (subjectively!) from the answers:</p>
  
  <ul>
  <li>Coordinator</li>
  <li>Builder</li>
  <li>Writer</li>
  <li>Reader</li>
  <li>Handler</li>
  <li>Container</li>
  <li>Protocol</li>
  <li>Target</li>
  <li>Converter</li>
  <li>Controller</li>
  <li>View</li>
  <li>Factory</li>
  <li>Entity</li>
  <li>Bucket</li>
  </ul>
  
  <p>And a good tip for the road:</p>
  
  <blockquote>
    <p>Don't get naming paralysis. Yes, names are very important but they're not important   enough to waste huge amounts of time on. If you can't think up a good name in 10 minutes, move on.</p>
  </blockquote>