Multiple Levels of Overloading Methods
I learned an interesting technique whenever I was looking at the Validation Application Block the other day. Each validator has an attribute associated with it, so you can define validation at the attribute level of a business object. So the following property of a business object can look like this:
[NotNullValidator]
public string Text { get; set; }
This essentially says that the text property is required. To validate this, reflection is used to extract the validator declarations for a property, and to call those validators with the designated business object property appropriately. All of this happens on the fly, and you don't have to worry about a thing this way. When creating custom validators, you do have a little more concern over how things are established. Like I said, each validator has an attribute, and you should do the same when creating custom ones yourself.
When creating a custom validator attribute, a base class of the ValidatorAttribute, or other specific ones like the ValueValidatorAttribute, provide some functionality for you, and require you to override the method:
Validator
DoCreateValidator(Type targetType);
However, there is another method that does the same thing:
Validator
DoCreateValidator(System.Type targetType, System.Type ownerType, Microsoft.Practices.EnterpriseLibrary.Validation.MemberValueAccessBuilder memberValueAccessBuilder)
The second overload gives you more of an ability to work with validators that validate other properties (like the PropertyComparisonValidator). In the base class, this method simply calls DoCreateValidator(targetType), and the first method has to be overridden. However, I realized something; the framework uses the second method first, and if you don't need to access other properties, then you can simply allow the call up the hierarchy.
But I thought that was interesting; the reason is you can override the second one, and that can be used for your specific needs and ignore the base class call to the first method. I thought that was interesting because essentially this develops a hierarchy of methods; sometimes you need the more detailed options, but if you don't the call propogates up the hierarchy to the less specific implementation. An interesting design pattern.