Naming Things Is Hard: Using Object Pattern Names

Design Patterns - tried-and-true solutions to common problems - have now been around long enough that many of them have very familiar names. We can use those names as part of an object-naming strategy.

The Factory Pattern

See? You've heard of this one, haven't you? Factory objects create instances of other objects, almost always Services. You might have to supply some sort of criteria, but you ask them for an instance of something, whizzy things happen and an instance is returned. The naming would look something like this:

public class WhizzyServiceFactory
    public WhizzyService Create()
        // Whizzy stuff omitted

        return new WhizzyService();

The Factory is named by appending the word 'Factory' to the type of object it creates, and the method is named Create. Why not CreateWhizzyService()? Because the object is a WhizzyServiceFactory - what else would it create?

The QueryObject Pattern

This pattern is less well-known than a Factory, and rather unhelpfully has two different implementations. The first - from Martin Fowler's Patterns of Enterprise Architecture - is an object which encapsulates a data store query, and is used as a parameter to a method on a Repository. The second - from CQRS - reverses the situation by knowing how to execute a particular query against a Repository it's given. QueryObjects are usually used to access Entities, but (for example) let's say we have a Service parsed from a pattern held in a datastore, like this:

public class WhizzyServiceParser
    public WhizzyService Parse(string pattern)
        // Whizzy parsing omitted

        return new WhizzyService();

public class GetWhizzyServiceQuery
    private readonly WhizzyServiceParser _parser;
    private readonly IRepository _repository;

    public GetWhizzyServicesQuery(
        WhizzyServiceParser parser, 
        IRepository repository)
        _parser = parser;
        _repository = repository;

    public WhizzyService Execute()
        return _parser.Parse(
_repository.GetWhizzyServicePattern()); } }

So here we have two patterns - Factory and QueryObject - which a component uses to retrieve instances of objects. The component uses each of them in exactly the same way, so as far as it's concerned they could both be named whizzyServiceSource with methods named Get(). But using the design pattern names and naming the methods in a way which indicates what's going on behind the scenes still wins because it provides information to colleagues, or your future self. Not to stereotype the interests of coding blog readers, but that's a bit science-fictiony, isn't it?

Clearly labelling a design pattern being used in a component provides information about what the object does, how it does it, how it should be used and how it's likely to behave, which is all well worth doing. This highlights the fact that careful naming not only helps describe the flow of a program, but also aids maintainability down the road.

Print | posted @ Wednesday, March 18, 2015 12:08 PM

Comments on this entry:

Gravatar # re: Naming Things Is Hard: Using Object Pattern Names
by carmen at 3/23/2015 12:57 PM

Naming everything is tiresome and sometimes hard to do but it does help you in the end. You can keep track of things better and other people can make better sense of your work. marina
Gravatar # re: Naming Things Is Hard: Using Object Pattern Names
by Lily at 3/23/2015 4:05 PM

I know that in programming really matter how you organize your work, just by the fact that it is important to appeal to some fireworks which facilitates us in the future correction programming mode. Calling each thing is an effective method to simplify the professional activity.
Post A Comment