Question

I’m attempting to implement a ‘Requirements’ type system into a program. It seemed pretty simple in my head, but actually making it abstract enough to be useful is proving more difficult than anticipated.

Here is what I am trying to do …

enum Condition {
 Not, Exists, Exceeds
}

abstract class Requirement { 
  // base class
  Condition Condition { get; set; }
}

class ScoreRequirement : Requirement {
  // a specific 'score' is required
}
class TraitRequirement : Requirement {
  // a specific 'trait' is required
}
class SatisfyingObject {
  // this is the class that has to satisfy the requirements
  IDictionary<Trait, int> Traits { get; set; }
}

If I know the exact thing that has to be satisfied in code-time, this is very simple. But the goal is to let people add requirements later. There will be other types that derive from Requirement, as well.

So a requirement might work like this …

var obj = new Item { 
 Requirements = new List<Requirement> {
   new ScoreRequirement { Trait = "One", Score = 2, Condition = Condition.Exceeds }
 }
}

So the concept seems pretty simple. You would call upon an object..

var satisfying = // get the satisfying object;

if( satisfying.Satisfies( obj.Requirements ) )
 return true;

The problem I am running into is really how to code the Satisfies method – in specific I am not sure how to relate it to the Condition parameter. I’d like people to be able to set up some fairly generic ‘requirements’, but the logic behind this is very confusing to me. Since the requirements are not known at design time, I cannot really hard code any of them.

Any suggestions?

Answer 1

If this isn’t a learning project than I would highly recommend you look at using something that is already built for this:

1. EntLib Validation Block
2. Fluent Validation
3. Anything built on top of the System.ComponentModel.DataAnnotations

If however you are doing this as a simple learning project, than you have 2 basic approaches you could take:

1. Reflection based
2. Delegate based

Of the two, delegate based is going to be much simpler to implement, but less flexible. I have implemented this pattern several times and the concept is simple. Here is about the most basic concept you can get.

public interface IRuleDefinition
{
    String PropertyName { get; }
    String Message { get; }
}

public class ValidationRule<T>: IRuleDefinition
{
    public String PropertyName { get; private set; }
    public String Message { get; private set; }

    private Func<T, Boolean> _isValidDelegate;

    public ValidationRule(Func<T, Boolean> isValidDelegate, String propertyName, String message)
    {
        PropertyName = propertyName;
        Message = message;
        _isValidDelegate = isValidDelegate;
    }

    public Boolean IsValid(T objToValidate)
    {
        return _isValidDelegate(objToValidate);
    }
}

public class Validator<T>
{
    private List<ValidationRule<T>> _validationRules = new List<ValidationRule<T>>();

    public void AddRule(Func<T, Boolean> isValidDelegate, String propertyName = null, String message = null)
    {
        _validationRules.Add(new ValidationRule<T>(isValidDelegate, propertyName, message));
    }

    public Boolean IsValid(T objToValidate)
    {
        return _validationRules.Any(vr => vr.IsValid(objToValidate));
    }

    public IEnumerable<IRuleDefinition> GetViolations(T objToValidate)
    {
        return _validationRules
             .Where(vr => !vr.IsValid(objToValidate))
             .Cast<IRuleDefinition>();
    }
}

You can use it in code like this:

var myObj = new MyObject{ Name = "Josh", Age = 29 };

var myObjValidator = new Validator<MyObject>();

myObjValidator.AddRule(
    obj => !String.IsNullOrWhitespace(obj.Name), 
    "Name", "Name is required!");

myObjValidator.AddRule(
    obj => obj.Age < 99,
    "Age", "Age must be less than 99");

myObjValidator.AddRule(
    obj => obj.Name == "Logan" && obj.Age < 29,
    message: "RUN!!!");

if(!myObjValidator.IsValid(myObj))
{
    foreach(var violation in myObjValidator.GetViolations(myObj))
        Console.WriteLine("Property: {0}, Message: {1}", 
            violation.PropertyName, violation.Message);
}

Now, this was all from memory, so there may be some are probably coding/compiler errors in all this, but hopefully you get the general idea.

Again, if this isn’t a learning project, then don’t reinvent the wheel unless you are planning to learn more about wheels 🙂