Dependency injection when the class created also needs runtime values?

Question

Assume you divide up your systems in Value objects and Services objects (as suggested in "Growing Object-Oriented Software, Guided by Tests". Misko Hevery calls these "newables" and "injectables".

What happens when one of your value objects suddenly needs to access a service to implement it's methods?

Let's say you have a nice simple Value object. It's immutable, holds a few bits of information and that's about it. Let's say we use it something like this:

CreditCard card = new CreditCard("4111-1111-1111-1111", "07/10");
if (card.isValid())
{
  // do stuff
} 
else
{
  // don't do stuff
}

So far so good. isValid() implements a check digit algorithm on the card number and returns true/false.

Now, let's say I wish to enhance the system by validating the expiry date against the current time. How would you suggest this is done without breaking the Value object/Service object paradim? I should like this class to continue to be unit testable.

• CreditCard now has a dependency, but because of the way it is created it can not be injected, so dependency injection is out.
• The CreditCard class should not be calling out to Singletons (I am of the position that global access to a Singleton is bad practice)
• Putting the behaviour on CreditCardVerificationService.validateCard() means all the existing code has to be revisited. The implementation of isValid() is leaking out.

I know there are things that can be done to get around this, but what is the cleanest way?

Answer 1

I would argue that it isn't a CreditCard object's job to validate anything. A factory would validate the check digits to ensure that it is instantiating a conforming card, while a verification service would validate the card for expiration/$ limit.

Answer 2

I would be tempted to say that CreditCard is not a Value Object.

From the C2 wiki:

Examples of value objects are things like numbers, dates, monies and strings. Usually, they are small objects which are used quite widely. Their identity is based on their state rather than on their object identity. This way, you can have multiple copies of the same conceptual value object.

A value object is not a BusinessObject/ReferenceObject. A BusinessObject/ReferenceObject is something you find in the world, while a ValueObject is a measure or description of something.

If CreditCardNumber could be a value object, CreditCard looks more like an business object which contains some business logic, e.g. validation.

I usually have Value Object, Service and Business Object. I don't know about "Growing Object-Oriented Software", but restricting yourself to only Value Object and Service seems odd to me.

Answer 3

I would call CreditCard an entity rather than a value object, since it's likely to be persistent and have a unique identity.

Anyway, it should be perfectly fine for an entity class to use service classes. If the implementations of said services don't need to be selected at runtime based on external configuration, then I would simply instantiate and use the desired service class inside the client method. Contrary to what some may think, this doesn't preclude unit testing, as a mocking tool can be used for isolation.

If the service implementation does need to be selected at runtime, than a Service Locator could be used. This pattern can provide direct support for mocking/faking, without the need for a specialized mocking tool. Use of a DI framework supporting injection into "newed" objects would be another alternative.