StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PONaming Classes - How to avoid calling everything a "<WhatEver>Manager"?
text
Body
copied!<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 & 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="http://rads.stackoverflow.com/amzn/click/0201633612" rel="noreferrer">Design Patterns: Elements of Reusable Object-Oriented Software (Hardcover)</a></li> <li>Book: <a href="http://rads.stackoverflow.com/amzn/click/0321127420" rel="noreferrer">Patterns of Enterprise Application Architecture (Hardcover)</a></li> <li>Book: <a href="http://rads.stackoverflow.com/amzn/click/0321413091" rel="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>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload