When I have a lot of data that needs to be validated, should I create a new class for the sole purpose of validation or should I stick with in-method validation?
My particular example contemplates a tournament and a event/category class: Tournament
and Event
, which models a sport tournament and each tournament has one or many categories.
There are all sort of things to validate in these classes: the players should be empty, should be unique, the number of matches each player should play, the number of players each match has, predefined matchups, and a really big etcetera including much more complex rules.
There are also some parts I need to validate as a whole, like how classes integrate with each other. For example, the unitary validation of a Player
can be just fine, but if an event has the same player twice, that's a validation error.
So how about this?: I forget about absolutely any pre-check when using my model classes' setters and similar methods to add data and instead I let validation classes handle that.
So we will have something like EventValidator
with an Event
as a member, and a validate()
method that validates the whole object, plus singular methods to validate all members' rules.
Then, before instantiating a validable object, I will execute the validation to prevent illegal values.
Is my design correct? Should I do something differently?
Also, should I use boolean returning validation methods? Or just throw an exception if the validation fails? It seems to me the best option would be boolean returning methods and throw the exception when the object is instantianted, for example:
public Event() {
EventValidator eventValidator = new EventValidator(this);
if (!eventValidator.validate()) {
// show error messages with methods defined in the validator
throw new Exception(); // what type of exception would be best? should I create custom ones?
}
}
Best Answer
It is OK to delegate any logic by means of composition if that logic is going to change dynamically during the execution of a program. Complex validations like the ones you explain are as good a candidate as any to be delegated to another class via composition.
Remember though that validations can occur in different moments.
Instantiating a concrete validator like in your example is a bad idea because it couples your Event class to that particular validator.
Let's assume you are not using any DI framework.
You can add the validator to the constructor, or inject it with a setter method. I suggest a creator method in a factory instantiates both the Event and the validator and then passes it either to the event constructor or with a setValidator method.
Obviously a Validator interface and or abstract class should be writen so your classes depend on it and not on any concrete validator.
Executing the validate method in the constructor can be problematic because all the state you want to validate may not be in place yet.
I suggest that you creta a Validable interface and let your classes implement it, that interface could have a validate() method.
That way the upper components of your application call the validate method at will (which in turn is delegated to the validator member).
==> IValidable.java <==
==> IValidator.java <==
==> Event.java <==
==> SimpleEventValidator.java <==
==> ValidationException.java <==
==> Test.java <==