CODEWITHSUNDEEP
javadesign-patterns
user1522820
user1522820

Reputation: 1604

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.

Upvotes: 5

Views: 1219

Answers (4)

Lightman
Lightman

Reputation: 1265

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

These checks become trivial if tackled from a data conversion point of view.

  1. List from a client is actually any list of any possible elements

  2. List from a client is to be converted to a well defined list of not duplicating not null elements

  3. This conversion can be decomposed into several simple conversions ToNonNull, ToNonNullList, ToNonDuplicatingList

  4. The last requirement is essentially conversion from two lists to one list of pairs ToPairs(ListA, ListB)

Put together it becomes:

ParentTableColumns = List1FromClient.
    ToNonNull.
    ToNonNullList.
    ToNonDuplicatingList

ChildTableColumns = List2FromClient.
    ToNonNull. 
    ToNonNullList.
    ToNonDuplicatingList

ParentChildColumnPairs = List.
    ToPairs(ParentTableColumns, ChildTableColumns)

If data from client is valid then all conversions succeed and valid result is obtained.

If data from client is invalid then one of the conversions fails and produces an error message.

Upvotes: 0

Abhishek Chatterjee
Abhishek Chatterjee

Reputation: 2049

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 oriented..by 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)
         e.validate();

      //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 entity...it is business logic, not validation logic

Upvotes: 4

dantuch
dantuch

Reputation: 9293

This is complex problem, so solution should be simplest possible to do not make it even more complicated and less understandable.

My approach would be:

some public method wrapping private method named something like doAllNeededListsValidationInFixedOrder() in which I'd create another private methods - each for every needed validation.

And ofc writing method like doAllNeededListsValidationInFixedOrder should be follow by some solid javadoc, even though it's not public.

If you want to go for pattern - the solution wouldn't be so straightforward. Basic thing to require checks in given order is to create lots or classes - every one for state telling that object is after one check, before another.

So you can achieve this with State pattern - treating every check as new state of object.

OR

You can use something like Builder pattern with forced order of methods invoked to create object. It is basically using a lot of interfaces to have every single (building) method (here validating) fired from different interface, to control order of them.

Going back to begining - using simple, well documenented and properly named method, that hides validating methods set, seems better for me.

Upvotes: 2

Thomas Uhrig
Thomas Uhrig

Reputation: 31605

I depends on you. There is no real argument against many checks. If your are developing an API, this can be very useful for other programmers. And it will make your own program more reliable.

I think the important point is, that you do your checks at one single point. You must have a clean and simple interface for your API. In this interface, it is ok to make checks. After these checks you could be sure that everything works.

What happens if you leaf the checks away? Will an exception be thrown somewhere or will the program just do something? If the program will just work and do something unpredictable, you should provide checks or things will begin to get strange. But if an exception will be thrown anyway, (I think) you can leaf the checks away. I mean, the program will get an exception anyway.

Upvotes: 2

Related Questions