标签云

微信群

扫码加入我们

WeChat QR Code

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.For example if my application was (as a typical business app) handling users, companies and addresses I'd have a User, a Company and an Address domain class - and probably somewhere a UserManager, a CompanyManager and an AddressManager would pop up that handles those things.So can you tell what those UserManager, CompanyManager and AddressManager do? No, because Manager is a very very generic term that fits to anything you can do with your domain objects.The article I read recommended using very specific names. If it was a C++ application and the UserManager'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 UserShepherd.Or maybe the UserManager's job is to examine each User object's data and sign the data cryptographically. Then we'd have a UserRecordsClerk.Now that this idea stuck with me I try to apply it. And find this simple idea amazingly hard.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 one 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.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 factory)Factory - Creates other objects (naming taken from the design pattern)Shepherd - A shepherd handles the lifetime of objects, their creation and shutdownSynchronizer - Copies data between two or more objects (or object hierarchies)Nanny - Helps objects reach "usable" state after creation - for example by wiring to other objectsetc etc.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.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: Naming Java Classes without a 'Manager'Update: Summary of answersHere's a little summary of what I learned from this question in the meantime.Try not to create new metaphors (Nanny)Have a look at what other frameworks doFurther articles/books on this topic:What names do you find yourself prepending/appending to classes regularly? What’s the best approach to naming classes?Book: Design Patterns: Elements of Reusable Object-Oriented Software (Hardcover)Book: Patterns of Enterprise Application Architecture (Hardcover)Book: Implementation Patterns (Paperback)And a current list of name prefixes/suffixes I collected (subjectively!) from the answers:CoordinatorBuilderWriterReaderHandlerContainerProtocolTargetConverterControllerViewFactoryEntityBucketAnd a good tip for the road: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.


It belongs in the community wiki because there is no one "best" answer. It's a discussion.

2019年10月20日34分54秒

That is counter intuitive.Shouldn't they call it a forum?I would think a wiki would be for a collection of facts, not opinions.

2019年10月20日34分54秒

Thanks for keeping this updated - but ugh, that last tip is terrible advice! If you can't think of a good name in 10 minutes, there's probably something wrong with your class. (With the standard caveats: 1) perfect is the enemy of good, 2) Shipping is a feature - just remember that you're incurring technical debt.)

2019年10月20日34分54秒

If you can't think up a good name in 10 minutes then ask your colleague for help. Don't just give up.

2019年10月21日34分54秒

If you can't think up a good name in 10 minutes, try explaining it to your colleagues; they might think of a good name (user338195), but trying to explain it will probably help you discover what's wrong with it (Jeff).

2019年10月21日34分54秒

I like these a lot. They do not fall into the trap of bad or unknown metaphors because they are already in use by the .NET Framework. It might be interesting to look at other libraries (Java), too for more input of what is commonly used.

2019年10月20日34分54秒

I would like to suggest Conductor, like the conductor of a musical orchestra. It's surely an important role, depending on the nature of collaborations you need to "conduct" (other objects being very specialized actors that should respond to centralized command and don't worry too much about every other collaborator).

2019年10月20日34分54秒

In one particular company long ago, I knew an engineer so fed up with the absurd and growing plethora of suffix rules plaguing the company that he defiantly ended every class with Thingy.

2019年10月20日34分54秒

This list of names by itself is not so useful without the context of which suffix should be applied.

2019年10月20日34分54秒

+1 for avoiding metaphors that could be difficult to understand for someone else

2019年10月20日34分54秒

This argument really breaks down in that obviously Factory itself is a metaphor.Often metaphors will really clear up what an object might be good at, whereas being vague or generic automatically ensures that the only way to figure out what the code does is by reading it fully!The worst case scenario.

2019年10月20日34分54秒

+1 for avoiding ‘cute’ names. I think it’s great to be as direct with language as you can be. (Of course, it’s not always easy being direct, succinct, precise and unambiguous all at the same time…)

2019年10月20日34分54秒

An inventive choice of verb + "er" is usually going to be clearer for concrete classes than a colorful analogy will. New abstractions, on the other hand -- stuff that's a new concept, a new "kind of thing" rather than just a new "thing" -- often do work well as metaphors (Java's "beans", Haskell's "lenses", GUI "windows", many languages' "promises"). Most codebases won't have any genuine inventions like that, though.

2019年10月20日34分54秒

How would you get to parallel universes and alternate dimensions?

2019年10月20日34分54秒

That's easy: Omniverse.Instance.Dimensions["Ours"].Universes["Ours"].Galaxies... ... okay okay I admit this would require a recompilation. ;-)

2019年10月20日34分54秒

Update: this was added in .NET 4.0: Universe.Instance.ToParallel() ;)

2019年10月20日34分54秒

Breaks demeter's law though!

2019年10月20日34分54秒

Those are Objects and Members, not Class names

2019年10月20日34分54秒

What about UserAccounter, UserProfiler and UserSecurer? If you get rid of Manager, you are forced to come up with the specific definition, which I think is a good thing.

2019年10月20日34分54秒

What about UserAccount, UserProfile, UserSecurity oO?

2019年10月20日34分54秒

I would name it "MortageOwnersManager"

2019年10月20日34分54秒

Sometimes the domain have specific names. Like "MortageHolder" that may be better that "MortageOwner"

2019年10月20日34分54秒

I really like the idea of using the Policy suffix for classes containing business logic

2019年10月20日34分54秒

Fowler is a good reference for me but the GOF is a great recommendation.

2019年10月20日34分54秒

Forgive my ignorance. Which Fowler book are you referring to ?

2019年10月20日34分54秒

amazon.com/Patterns-Enterprise-Application-Architecture-Martin/…

2019年10月20日34分54秒

Hmm, sometimes this works (for example like a Factory or a Strategy) but in other times I feel that this does communicate the way of implementation (I used a pattern!) more than the intent and job of the class. For example a Singleton's most important thing it what it represents - and not that it is a Singleton.So strict naming after the patterns used feels like strict naming after the types used. For example Hungarian notation as mis-applied by the Windows Systems group (describing the C data type instead of "intent type")

2019年10月20日34分54秒

For technical infrastructure classes, it's usually desirable to make the implementation transparent - and most of the canonical design pattern names communicate both implementation and intent. Domain model classes are another matter, though.

2019年10月20日34分54秒

I also really like this approach because it eases off the idea of top down management of objects.A group of users is more likely to imply that work is done between users instead of from the UserManager down.Also, having a User own a reference to Users does not feel as strange as owning UserManager.It's more open to relative thinking, rather than strictly OOP.

2019年10月20日34分54秒

Still, a consistent if slightly unintuitive convention is better than just starting your own convention. People working on a project will learn any consistent convention very fast and soon forget that the functionality isn't quite what might be expected on first glance.

2019年10月20日34分54秒

John, that's exactly what I said. The convention needs to be accepted by the group and if you are working in a company then see if there is a company convention. For company I'm thinking of any group, be it an open source project team or a loose collection of programmers. If everyone just took what was available that almost fit their requirements then I think we'd be sorely lacking in innovation.

2019年10月20日34分54秒

I have commented on that on Brian Agnew's answer. I don't feel the pattern names make good class names only in some cases (Factory, Strategy) but not in others (Singleton). I want the names to reflect the job of the class not the way how I implemented it.

2019年10月20日34分54秒