And you are right, ubiquitous language is the most important point here, and _if_ time/clock is an essential part of the domain, then it’s wise to use the term domain experts find best.

Otherwise (in most cases?) naming an internal detail like this is more a matter of taste (of the developers involved).

You don’t sound too critical and I do appreciate hearing your point of view. You have lots of good points. Here are some responses…

You could still argue over the merits of TimeProvider but I still don’t know anyone (outside of programmers) that would call a Clock that. Even *nix people call it the system clock (not a system time provider). You talk about other aspects and depending on what you were modelling, could potentially all be valid. I would say though that all clocks tell the time, yet all clocks do not have all the properties you mention (alarms, dimensions, etc).

For some programmers, mathematics might be very useful for communicating, but I also believe in the Ubiquitious Language and even then, mathematics is not often the best choice for this.

I also agree that minimalism can exist with readability.

But finding the provider interface isn’t so easy. The best way that pops into my mind is to find references to the interface or even to a constructor of some implementation.

I agree, readability is at least as important as convenience. But I believe minimal vocabulary can coexist with readability.

Mathematics is a good example: most laymen find mathematical jargon clumsy and dull (and unreadable), but I believe it’s quite optimal the way it is, after generations of evolution.

And, many projects “overload” seemingly universal concepts with project-specific semantics anyway (like you said, “not all classes will match real world concepts”). Or, even more likely, they simplify the concepts.

Take Clock, for example. Does our program need any physical properties of the clock instrument, like dimensions? Is it a digital or an analog clock? Does it have alarm functionality? Does it ring a bell every hour? If not, maybe we don’t need the whole Clock interface, only a little part of it, namely a provider for time.

Well, I hope I don’t sound too critical. Clock is also a good name, but I just wanted to show that the “classical” naming can also be something else than a learned bad habit.

Thanks for your comment. I can appreciate the need to consider leaving code that needs to cross multiple cultures and languages. I understand that calling something X and XProvider is easy, and may be conventional for many programmers, however I still prefer to name my classes to leave as much intent in them as possible.

Although I could name a class XProvider, what does that tell future programmers? What other characteristics should it have? If I can’t think of a better name, I prefer to name things DefaultX instead.

I also believe that finding implementations of X shouldn’t be hard for developers these days with excellent tools like Eclipse and IntelliJ showing us inheritors or class hierarchies with a short keyboard shortcut (or click away). Javadoc, albeit slower, also gives us access to the same information.

I will admit that not all classes will match real world concepts, but it doesn’t mean that we should be lax on the principle of programming for readability vs programming for convenience.

I understand your point about naming: mainstream OO naming is sometimes humorous and clumsy, and more “natural” naming has its merits.

On the other hand, just like an electronic office shouldn’t just mimic paper office, maybe the language in code could also do better than its real-life counterpart.

The richness of natural languages is of course a blessing for art and other human activity, but in code certain minimalism and consistency is good.

If I need any X in my code, it’s easy if I can just see if there is an interface named XProvider to be injected, instead of having to activate my (non-native) English skills and find the correct natural term for the provider.

Program code isn’t supposed to be read in a poetry competition, after all, it’s supposed to be effective enough to be even boring sometimes

- Ville Oikarinen
comment provider

Thanks for your comment. I didn’t know that this was here as an option. I’m still a little bit uncomfortable using static methods for anything like this, but it could certainly be useful for people as a starting place.

to set the time you want used by the rest of joda, such as when new DateTime() is called.

in the tearDown for your test, restore it with:

org.joda.time.DateTimeUtils#setCurrentMillisSystem()

This allows the codebase to use new DateTime() whenever the current time is required, without needing to inject some other interface to facilitate controlled testing.