For my part, I make a lot of use of agent-noun classes: my most recent code includes StringTokenizer, BindVariableExtractor, BindVariableResolver, FieldValueGetter (which implements IValueGetter), FieldValueSetter (IValueSetter), and others. To me, this is correct, as these classes have no dependencies and can be rewritten, replaced, mocked and tested without impacting the rest of the system. That is what is important to me, and it makes my code easy to read for me and those who come after me.

So I’d stick with AgeCalculator and call it from a getAge method.

Let me remind you that Type + Contstraint = New Type.
So, + = Age type.

This transformation also falls nicely into Wrap Primitive with Object refactoring, which attacks Primitive Obsession anti-pattern.

Therefore your Customer class may have a method like

Age getAge() { return new Age(this.dateOfBirth); }

Uladzimir.

For example the last two classes that I mentioned hook into Java’s serialization process. In this system, when objects are serialized, there are about five things that need to be checked about every object. Each of those things is implemented as one SerializationListener or SerializationReplacer (similar to the Visitor pattern) and verb names felt natural because each of them does one action, similar to how a method does one action. They are used like this:

http://github.com/orfjackal/dimdwarf/blob/master/dimdwarf-core/src/main/java/net/orfjackal/dimdwarf/serial/ObjectSerializerImpl.java

It is probably overkill to break out the interface in this scenario, so AgeCalculator is a fine “generic” strategy for calculating ages.

(I wouldn’t change a thing).

I’ve also hit this problem before. Like many posts I try and create a class which represents the result (e.g. Age).

So I would do something like: dateOfBirth.AgeOn(Clock.Now)

In which case the names would stay the same and we wouldn’t need to find a new class name! I’m not sure what the best thing would be to do in Java though maybe those names are fine in that case.

When I actually come across a situation like this *AgeCalculator* I would usually name it *CalculateAgeCommand*.

I am not sure whether it makes it smell less, but all my commands have a common interface:

interface ICommand {
//constructor gets all dependencies
T Execute();
}

So, I know when an operation is complex enough to deserve its own tests, I promote it from a private method to a class that implements my ICommand interface.