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.
The input validator pattern provides an architecture for securing an application from malicious input.
Model validation refers to the process of confirming that the model achieves its intended purpose i.e., how effective our model is.
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:
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:
Maybe you could implement the Strategy Pattern to your Factory (method)
to provide some validation capabilities:
public interface DataValidationStrategy {
boolean isValid(SetOfData<SomeType> setofdata);
}
public class ThresholdValidation implements DataValidationStrategy {
private int threshold;
public ThresholdValidation(int threshold) {
this.threshold = threshold;
}
@Override
public booleam isValid(SetOfData<SomeType> setofdata) {
return setofdata.count > threshold;
}
}
Now create as many different validation classes
as you require and then change your create
method:
public static Create(SetOfData<SomeType> setofdata, DataValidationStrategy validation)
{
if (validation.isValid(setofData))
{
return new BusinessObject(setofdata);
}
else
{
return null;
}
}
Edit: In addition you might consider using a prototype or a null object instead of a null
return value.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With