user1522820 user1522820 - 4 years ago 82
Java Question

How to handle a lot of validation checks necessary before creating a object?

I have a class which models FK relationship. It has 2 lists in it. These lists contains the column names of the Parent Table & the Child Table respectively. These lists are passes by the client to me. Now before creating my FK object, I think it is necessary to do following checks (in order):

  1. Check if lists are not null.

  2. Check if lists contains null.

  3. If a list contains duplicates columns?

  4. Size of both the lists are equal.

So you can see there will be total 7 checks. Is it OK to have so many checks?

If it is OK to have these many checks, is there any pattern to handle such cases (with high no. of validation checks)?

If it is not OK, then what should I do? Should I just document these conditions as part of contract & mention that API will produce nonsensical results if this contract is violated?

Edit : Basically, I am trying to takes these 2 lists & produce a Database specific Query. So, it is kind of important to have this object built correctly.

Answer Source

Like everybody says, it depends on you. There is no such fixed/standard guideline for this. But to make it simple, you must have to put all your validation logic in one place, so that it remains readable and easy to change.

A suggestion can be, as you said, all of your validation logic seems to be very business which I mean the end user should not be bothered about your db configuration. Let assume your class name, FKEntity. So if you follow the entity concept then you can put the validation logic in FKEntity.validate() (implementing an interface Validatable) which will validate the particular entity...this is for those kind of validation logic which applies to all FKEntity type objects in same way. And if you need any validation logic that compares/process different FKEntity depending on each other (e.g. if there is one FKEntity with some value "x" then no other entity can have "x" as their values, if they do, then you can not allow the entire entity list to persist), then you can put the logic in your Service layer.

Inteface Validatable { void validate() throws InvalidEntityException; }   

Class FKEntity implements Validatable {
  public void validate() throws InvalidEntityException {
     //your entity specific logic

Class FKDigestService {

    public digestEntities() {

      try {
      for(FKEntity e : entityList)

      //your collective validation logic goes here
      } catch (EntityValidationException e) {//do whatever you want}


This will give you two advantages,

  1. Your entity specific validation logic is kept in a single place (try to think most of the logic as entity specific logic)

  2. Your collective logic is separated from entity logic, as you can not put these logic in your entity since these logic is only applicable when there is a collection of FKEntity, but not for single is business logic, not validation logic

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download