<p>Coming up with good, precise names for classes is notoriously difficult. Done right, it makes code more self-documenting and provides a vocabulary for reasoning about code at a higher level of abstraction. </p>

<p>Classes which implement a particular design pattern might be given a name based on the well known pattern name (e.g. FooFactory, FooFacade), and classes which directly model domain concepts can take their names from the problem domain, but what about other classes? Is there anything like a programmer's thesaurus that I can turn to when I'm lacking inspiration, and want to avoid using generic class names (like FooHandler, FooProcessor, FooUtils, and FooManager)?</p>

[{'answer_id': 38042, 'author': 'Luke Halliwell', 'author_id': 3974, 'author_profile': 'https://Stackoverflow.com/users/3974', 'pm_score': 3, 'selected': False, 'text': "<p>If a good name doesn't spring to mind, I would probably question whether there is a deeper problem - is the class serving a good purpose?  If it is, naming it should be pretty straightforward.</p>\n"}, {'answer_id': 38048, 'author': 'Rob Cooper', 'author_id': 832, 'author_profile': 'https://Stackoverflow.com/users/832', 'pm_score': 5, 'selected': False, 'text': '<p>Always go for MyClassA, MyClassB - It allows for a nice alpha sort.. </p>\n\n<p><strong>I\'m kidding!</strong></p>\n\n<p>This is a good question, and something I experienced not too long ago. I was reorganising my codebase at work and was having problems of where to put what, and what to call it..</p>\n\n<p>The <strong>real</strong> problem?</p>\n\n<p>I had classes doing too much. If you try to adhere to the <a href="http://en.wikipedia.org/wiki/Single_responsibility_principle" rel="noreferrer">single responsibility principle</a> it will make everything all come together much nicer.. Rather than one monolithic <em>PrintHandler</em> class, you could break it down into <em>PageHandler</em> , <em>PageFormatter</em> (and so on) and then have a master <em>Printer</em> class which brings it all together.</p>\n\n<p>In my re-org, it took me time, but I ended up binning a lot of duplicate code, got my codebase much more logical and learned a hell of a lot when it comes to thinking before throwing an extra method in a class :D</p>\n\n<p>I would <strong>not</strong> however recommend putting things like pattern names into the class name. The classes interface should make that obvious (like hiding the constructor for a singleton). There is nothing wrong with the generic name, if the class is serving a generic purpose.</p>\n\n<p>Good luck!</p>\n'}, {'answer_id': 38055, 'author': 'Simon Johnson', 'author_id': 854, 'author_profile': 'https://Stackoverflow.com/users/854', 'pm_score': 4, 'selected': False, 'text': '<p>If you\'re stuck with a name, sometimes just giving it <a href="http://lbrandy.com/blog/2008/08/developer-timesink-name-paralysis/" rel="noreferrer"><i>any</i></a> half-sensible name with commitment to revising it later is a good strategy.</p>\n\n<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>\n'}, {'answer_id': 38095, 'author': 'McKenzieG1', 'author_id': 3776, 'author_profile': 'https://Stackoverflow.com/users/3776', 'pm_score': 2, 'selected': False, 'text': '<p>If your "FooProcessor" really does process foos, then don\'t be reluctant to give it that name just because you already have a BarProcessor, BazProcessor, etc. When in doubt, obvious is best. The other developers who have to read your code may not be using the same thesaurus you are.</p>\n\n<p>That said, more specificity wouldn\'t hurt for this particular example. "Process" is a pretty broad word. Is it really a "FooUpdateProcessor" (which might become "FooUpdater"), for example? You don\'t have to get too "creative" about the naming, but if you wrote the code you probably have a fairly good idea of what it does and doesn\'t do.</p>\n\n<p>Finally, remember that the bare class name isn\'t all that you and the readers of your code have to go on - there are usually namespaces in play as well. Those can often give readers enough context to see clearly what your class if really for, even if its bare name is fairly generic.</p>\n'}, {'answer_id': 48001, 'author': 'Marcio Aguiar', 'author_id': 4213, 'author_profile': 'https://Stackoverflow.com/users/4213', 'pm_score': 7, 'selected': True, 'text': '<p>I\'ll cite some passages from <a href="https://rads.stackoverflow.com/amzn/click/com/0321413091" rel="noreferrer" rel="nofollow noreferrer">Implementation Patterns</a> by Kent Beck:</p>\n<h2>Simple Superclass Name</h2>\n<blockquote>\n<p>&quot;[...] The names should be short and punchy.\nHowever, to make the names precise\nsometimes seems to require several\nwords. A way out of this dilemma is\npicking a strong metaphor for the\ncomputation. With a metaphor in mind,\neven single words bring with them a\nrich web of associations, connections,\nand implications. For example, in the\nHotDraw drawing framework, my first\nname for an object in a drawing was\n<strong>DrawingObject</strong>. Ward Cunningham came\nalong with the typography metaphor: a\ndrawing is like a printed, laid-out\npage. Graphical items on a page are\nfigures, so the class became <strong>Figure</strong>.\nIn the context of the metaphor, <strong>Figure</strong>\nis simultaneously shorter, richer, and\nmore precise than <strong>DrawingObject</strong>.&quot;</p>\n</blockquote>\n<h2>Qualified Subclass Name</h2>\n<blockquote>\n<p>&quot;The names of subclasses have two jobs.\nThey need to communicate what class\nthey are like and how they are\ndifferent. [...] Unlike the names at\nthe roots of hierarchies, subclass\nnames aren’t used nearly as often in\nconversation, so they can be\nexpressive at the cost of being\nconcise. [...]</p>\n<p>Give subclasses that serve as the\nroots of hierarchies their own simple\nnames. For example, <em>HotDraw</em> has a\nclass <strong>Handle</strong> which presents figure-\nediting operations when a figure is\nselected. It is called, simply, <strong>Handle</strong>\nin spite of extending <strong>Figure</strong>. There is\na whole family of handles and they\nmost appropriately have names like\n<strong>StretchyHandle</strong> and <strong>TransparencyHandle</strong>.\nBecause <strong>Handle</strong> is the root of its own\nhierarchy, it deserves a simple\nsuperclass name more than a qualified\nsubclass name.</p>\n<p>Another wrinkle in\nsubclass naming is multiple-level\nhierarchies. [...] Rather than blindly\nprepend the modifiers to the immediate\nsuperclass, think about the name from\nthe reader’s perspective. What class\ndoes he need to know this class is\nlike? Use that superclass as the basis\nfor the subclass name.&quot;</p>\n</blockquote>\n<h2>Interface</h2>\n<blockquote>\n<p>Two styles of naming interfaces depend on how you are thinking of the interfaces.\nInterfaces as classes without implementations should be named as if they were classes\n(<em>Simple Superclass Name</em>, <em>Qualified Subclass Name</em>). One problem with this style of\nnaming is that the good names are used up before you get to naming classes. An\ninterface called <strong>File</strong> needs an implementation class called something like\n<strong>ActualFile</strong>, <strong>ConcreteFile</strong>, or (yuck!) <strong>FileImpl</strong> (both a suffix and an\nabbreviation). In general, communicating whether one is dealing with a concrete or\nabstract object is important, whether the abstract object is implemented as an\ninterface or a superclass is less important. Deferring the distinction between\ninterfaces and superclasses is well &gt;supported by this style of naming, leaving you\nfree to change your mind later if that &gt;becomes necessary.</p>\n<p>Sometimes, naming concrete classes simply is more important to communication than\nhiding the use of interfaces. In this case, prefix interface names with “I”. If the\ninterface is called <strong>IFile</strong>, the class can be simply called <strong>File</strong>.</p>\n</blockquote>\n<p>For more detailed discussion, buy the book! It\'s worth it! :)</p>\n'}, {'answer_id': 48019, 'author': 'Josh Segall', 'author_id': 2659, 'author_profile': 'https://Stackoverflow.com/users/2659', 'pm_score': 5, 'selected': False, 'text': '<p>Josh Bloch\'s excellent talk about <a href="http://youtube.com/watch?v=aAb7hSCtvGw" rel="noreferrer">good API design</a> has a few good bits of advice:</p>\n\n<ul>\n<li>Classes should do one thing and do it well.</li>\n<li>If a class is hard to name or explain then it\'s probably not following the advice in the previous bullet point.  </li>\n<li>A class name should instantly communicate what the class is.</li>\n<li>Good names drive good designs.</li>\n</ul>\n\n<p>If your problem is what to name exposed internal classes, maybe you should consolidate them into a larger class.</p>\n\n<p>If your problem is naming a class that is doing a lot of different stuff, you should consider breaking it into multiple classes.</p>\n\n<p>If that\'s good advice for a public API then it can\'t hurt for any other class.</p>\n'}]
['https://Stackoverflow.com/questions/38019', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/3598/']