Question

I’m creating interfaces and abstract classes that represent a messaging framework for short text-based messages like SMS, email, twitter, xml, etc.. and I was wondering where I should put the message validation code.

The thing is that I am only writing the superclasses and interfaces, so I’m not putting the actual implementation in, I’ll just put the hooks in that allow others to validate the content of the messages. The way I see it, I could do it several ways:

• in the abstract superclass “Message”, have an abstract method ‘isValid’. A variation on this would be to have isValid be called when the Message constructor is called, throwing a MalformedMessageException if the message is formatted incorrectly.

• in the transport layer, immediately before sending, validate the message. I would have a send(Message) method that calls an isValid(Message) method immediately before it sends.

• have a singleton message validator with a static method isValid(Message) that is called at some point.

I’m sure there are other options that I’m missing. Currently, I’m leaning towards the first one, but it doesn’t feel right to me to have validation code in what should be a domain object.

Answer 1

Message is one thing. A container of data.

Validation is a separate thing. Validation is separate from the Message because validation depends on non-Message data. Validation includes one or more algorithms that establishes if a valid Message could be built from some data.

You want Messages to be built only when they’re valid. You want all of the the methods of a message to require and depend on validity. That gives you easy-to-understand responsibility.

Therefore, a Message should not contain any validation logic. That logic lives just outside the boundaries of a valid Message. It’s part of a MessageFactory or MessageValiadtor that determines if some given puddle of data could be used to build a valid Message.

You have two things: MessageValidator (or MessageFactory) and Message.

There is no isValid in a Message. It must be valid or it would not exist.

MessageValidator builds Messages from source data. If it cannot build a message can can throw an exception. It should also accumulate the list of errors it finds so it can be interrogated to determine what the various problems were.

Consider the possible mutations: Multiple variant subclasses of Message. The Validator may identify a specific subclass. No application changes are required to implement this.

Multiple Validators for special situations, exceptions, extensions, etc. It’s just a subclass of MessageValidator with the same interface all validators have and emits an instance of Message (or one of it’s subclasses.)

Since the validation rules are separate from a valid message, the Validator can provide different assumed defaults or derived data, also.