Search code examples
c#javadesign-patterns

What design pattern to use for validating data and creating an object


I often come across situations where a I want to create an instance of an object by passing it some given data or maybe another object but the data or object needs to be valid or in the right state. I am always a bit unclear on the 'correct' way of doing this. Here is my example:

Given this class:

class BusinessObject()
{
    const Threshold = 10;

    public BusinessObject(SetOfData<SomeType> setofdata)
    {
        // an example of some validation
        if (setofdata.count > Threshold)
        {
            // performance some business logic
            // set properties
        }
    }
}

It is possible to run into some problems if you do this:

var setofdata = new SetOfData<SomeType>();

// if data is not valid then the object will be created incorrectly
var businessObject = new BusinessObject(setofdata);

So my solutions have always been either:

class BusinessObjectBuilder()
{
    public BusinessObject Build(SetOfData<SomeType> setofdata)
    {
        // an example of some validation
        if (setofdata.count > Threshold)
            return new BusinessObject(setofdata);
        }
        else
        {
            return null;
        }
    }
}

Or make the constructor private and add a static factory method:

class BusinessObject()
{
    const Threshold = 10;

    public static Create(SetOfData<SomeType> setofdata)
    {
        if (setofdata.count > Threshold)
        {
            return new BusinessObject(setofdata);
        }
        else
        {
            return null;
        }
    }

    private BusinessObject(SetOfData<SomeType> setofdata)
    {
        // performance some business logic
        // set properties
    }
}

ideally I would not like to throw an exception if the data is invalid as there might be multiple business objects being created in one process and I don't want the whole process to fail if one validation fails and catching and suppressing exceptions is not good.

Also all examples I read of the Abstract Factory or Factory method involve passing in some type or enum and a correct object being built and returned. They never seem to cover this scenario.

So what are the conventions in this scenario? Any advice would be greatly appreciated.


Solution

  • IMHO constructor validation is the best for many situation where you need to make sure that no object can be created unless specified parameter being set.

    public class BusinessObject
    {
        const Threshold = 10;
    
        public BusinessObject(SetOfData<SomeType> setofdata)
        {
            // an example of some validation
            if (setofdata.count > Threshold)
            {
                throw new InvalidOperationException("Set data must be above treshold");
            }
        }
    }
    

    However, this has bad implementation when:

    • You may have invalid object such as when in draft status, etc
    • Used in ORM when default constructor needed
    • If heavy validation logic occurs.

    For point no.1 and 2, I cannot suggest any other option except request - validate - submit mechanism.

    For point no.3, the reason is, the class will do too much for validation itself and creating a monolithic code. If there is much validation logic, I suggest to implement builder pattern with injected validator, and make the constructor of BusinessObject internal.

    public class BusinessObjectBuilder
    {
        public BusinessObjectBuilder(IBusinessObjectValidator validator){
            this.validator = validator;
        }
        IBusinessObjectValidator validator;
    
        public BusinessObject Build(SetOfData<SomeType> setofdata)
        {
            // an example of some validation
            if (validator.IsValid(setofdata))
                return new BusinessObject(setofdata);
            }
            else
            {
                throw new //exception
            }
        }
    }
    

    This enforce modular programming and prevent monolithic code.

    Both of the code is:

    • easy to test
    • easy to review
    • extendable