There's nothing more ambiguous than a SomethingManager. Avoid this word. Alan Green proposes a few alternatives in his blog post that might be helpful in narrowing down what your class actually does.
Giving your classes and objects good, descriptive names isn't easy. Steve McConnell provides a few helpful guidelines for routine naming in Code Complete:
- Describe everything the routine does And we mean literally everything. If that makes the name ridiculously long, the name isn't the problem. Your routine is.
- Avoid meaningless, vague, or wishy-washy verbs
Like
UrlManager, orHandleOutput, orPerformServices. Be specific. What does it do? If you can't answer that question succinctly, it may be time to refactor the code until you can. - Don't differentiate routine names solely by number
I include this only for completeness. If you ever find yourself writing
OutputUser1andOutputUser2, God help you. And God help the team you work with. - Make names as long as necessary According to McConnell, the optimum name length for a variable is 9 to 15 characters; routines tend to be more complex and therefore deserve longer names. Make your names as long as they need to be in order to make them understandable.
- For functions, try using a description of the return value An easy, straightforward rule. Some examples are printer.IsReady(), pen.CurrentColor(), etcetera.
- Use opposites precisely
- for every
Open, there should be anterprise Integration Design PatternsClose - for every
Insert, aDelete - for every
Start, aStop
- Establish conventions for common operations
I'd say renaming classes and variables is one of my most frequent refactoring activities. Creating good names is hard, but it should be hard, because a great name captures essential meaning in just one or two words.
It's difficult to tell what something should be named until you're completely finished writing it. And like most code, it's never quite done, so the name may change over time. Succinct, descriptive variable, object, and function names can make the difference between wtf code and… well, code you'd actually want to work on.
- (see original resource: I shall call it SomethingManager)
Design Patterns are typical solutions to commonly occurring problems in software design. They are blueprints, that can be taken and customized to solve a particular design problem in your code.
- (see original resource: Design Patterns or wikipedia)
| Class suffix | Descripption |
|---|---|
| Storage | Stores something for future use. |
| Repository | Repository isolates domain objects from details of the database access code. The mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes. Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. |
| Mapper (DataMapper) | Data Mapper moves data between objects and a database while keeping them independent of each other and the mapper itself. |
| Provider (DataProvider) | Provides a uniform interface between a service and a data source. Providers abstract physical storage, in much the same way that device drivers abstract physical hardware devices. |
| Reader | Reads the data from the resources. |
| Writer | Writes the data to the resources. |
| Importer | |
| Exporter | |
| Builder (Creator) | Builder is a creational design pattern that lets you produce different types and representations of an object using the same building process. Builder allows constructing complex objects step by step. |
| Fetcher | Retrieves data from the different resources like rss etc. |
| Splitter | Breaks out the composite data(message) into a series of individual data(messages), each containing data related to one item. See also Messaging Pattern: Splitter. |
| Agregator | Collects and store individual data(messages) into one composite data(message). The opposite to the Splitter. See also Messaging Pattern: Agregator. |
| Serializer | Translates data structures or object state into a format that can be stored (for example, in a file or memory buffer) or transmitted (for example, across a network connection link) and reconstructed later (possibly in a different computer environment). See also: Serialization |
| Transformer (DataTransformer) | A transformer only changes one attribute, so that the result is the same basic type, but of a different capacity or intensity (voltage for example). |
| Collector | Collector is responsible for gathering the data. |
| Adapter, Wrapper, or Translator | Converts the interface of a class into another interface clients expect. An adapter lets classes work together that could not otherwise because of incompatible interfaces. The enterprise integration pattern equivalent is the translator. |
| Formatter | Formatter converts the data into a specific format based on the client needs. An example of a formatter would be converting the data to JSON or XML format. |
| Normalizer | Normalizes data from different resources to a common format. See also Messaging Pattern: Normalizer. |
| Converter | A converter makes the resulting object different in type from then initial condition, for example changing alternating current to direct current. |
| Handler (EventHandler, FormHandler) | The main role and intent of the Handler is to handle stuff:
|
| Activator | The Activator design pattern automates scalable on-demand activation and deactivation of service execution contexts to run services that can be accessed by many clients. |
| Checker | |
| Validator | More details JSR303 Bean Validation specification |
| Parser | The Parser can be used to parse or convert one structure into another. This can be XML to objects or objects to XML or from one abstract definition into another; for instance: XML to JSON and the other way around. This can also mean one object structure into another object structure, representing the same thing in a different way. |
| Matcher | |
| Uploader | |
| Copier | |
| Analyzer | |
| Calculator | |
| Refunder | |
| Subscriber | |
| Unsubscriber | |
| Navigator | |
| Visitor | Visitor is a behavioral design pattern that lets you define a new operation without changing the classes of the objects on which it operates. |
| Authenticator | The Authenticator pattern describes a general mechanism for providing identification and authentication to a server from a client. It has the added feature of allowing protocol negotiation to take place using the same procedures. The pattern operates by offering an authentication negotiation object which then provides the protected object only after authentication is successful. |
| Initializer | |
| Installer | |
| Synchronizer | |
| Encryptor | |
| Decryptor | |
| Iterator | Iterator is a behavioral design pattern that lets you access the elements of an aggregate object sequentially without exposing its underlying representation. |
| Collection | Stores objects in an organized way that follows specific rules. |
| Genereator | |
| Scheduler | Allows to schedule and track tasks. |
| Runner | Run the task that returns a result and may throw an exception. |
| Executor | Represents an execution mechanism which is runnable of executing tasks that do not return a result and cannot throw a checked exception. |
| Delegator | Refers to evaluating a member (property or method) of one object (the receiver) in the context of another. See also: Delegation pattern and Delegation |
| Invoker | |
| Logger | More details PSR-3 or RFC 5424 |
Also take a look at source-code-wordle.de. This resource contains a lot of suggested names that have been extracted from a huge amount of code. It will help you to find and determinate naming strategy for your specific classes and services.