views:

232

answers:

9

I have a few classes in my current project where validation of Email/Website addresses is necessary. The methods to do that are all the same.

I wondered what's the best way to implement this, so I don't need to have these methods copy pasted everywhere?

The classes themselves are not necessarily related, they only have those validation methods in common.

+5  A: 

You might want to put all the validation code into a Validator class, then use that class anywhere that validation is needed. Access to validation should be through a single method, Validate(object Something) maybe. I think this is called "Composition" (as far as design patterns go).

Later on, you can have sub-classes of Validator that maybe more specific or do different kinds of validation.

You could also have all classes requiring validation extend a base class or abstract class that has 90% of the validation in it.

FrustratedWithFormsDesigner
The best term is "Association", which is a class relationship (http://en.wikipedia.org/wiki/Class_diagram#Instance_Level_Relationships) rather than a pattern. As for patterns, the strategy pattern (http://en.wikipedia.org/wiki/Strategy_pattern) might be involved.
outis
+13  A: 

How about adding an interface, and using an extension method?

public interface IFoo { }

public class A : IFoo {}
public class B : IFoo {}
public class C : IFoo {}

public static class FooUtils {
    public static void Bar(this IFoo foo) { /* impl */ }
}

That way:

  • no unnecessary inheritance
  • no duplication
Marc Gravell
Inside class A, can I now access the method Bar?
Tony
Yep var aClass = new A(); aClass.Bar();
masenkablast
looks like extension method abuse to me. why'd you require all classes that need email validation to implement some (empty) interface and do some extension method magic on it if they could instead simply call a static method of an EmailUtils class (or create an EmailValidator object and call the Validate method on it)? also it seems like he only needs the email validation code inside the classes - that shouldn't require the implementation of an interface.
stmax
This is certainly a bad use of interfaces and extension methods. Quite scary that it received the most votes and was marked as the answer.
whatispunk
That sounds as an "exploit" to overcome the lack of multiple class inheritance in C#. It might sound conceptually wrong, but the result would be the same as inheriting from the "Foo" class with it's own implementation of "Bar". Problems come when you have to also inherit from another class, and that's where Marc's solution come by.
Alex Bagnolini
A: 

create validation logic classes and interfaces, and have them being injected in your code... so seperate the logic from validation so that it can be reused...

Tim Mahy
+1  A: 

Create a Utility class and define these methods as extension methods for appropriate class/interfaces.

Vivek
+2  A: 

Yes, duplicating this code would be a bad smell, you can extract these methods to single Helper class in static methods or you can define a "Validator" interface class and using this interface, you can link different validation methods with chain of responsibility pattern.

baris_a
+4  A: 

Sounds like you just need a static class with a static method

public static class Utilities{
    public static bool validEmail(string email)
    {
        //Your code here
    }
}
juharr
+1 for simplicity instead of extension method misuse.
stmax
+1 Utility class seems like the way to go here. Have a Utility class with static methods that validate email, check web addresses and other kind of validations. And call this Utility static methods whenever you need those methods.
Helen Neely
A: 

Create Email as a separate class.
Use Email as properties/parameters/return values in your classes instead of String.
Create EmailValidator to validate strings as email addresses.
Create EmailFactory that returns Email when passed a valid email address and null if not.

(Do same for Website).

Even Mien
+1  A: 

You really need to take a good look at the aspect oriented programming methodology (AoP). The Enterprise Library 4.1 has an AoP implementation called Unity Interception.

http://msdn.microsoft.com/en-us/library/dd140045.aspx

This framework allows you to code a single handler class for the email validation. So what this entails is that the validation code goes into a handler class, and no longer part of the class(es). Next thing you do is mark the classes for interception.

You can intercept the classes in a variety of ways, including setting an attribute on the desired method that should be intercepted and handled per your requirements. Setting an attribute is probably the easiest way to do an interception.

code4life
A: 

I would recommend you create an IValidator interface then create multiple different validators that handle different scenarios. Here's one example:

public interface IValidator {
    bool CanValidateType(string type);
    bool Validate(string input);
}

The CanValidateType() method could be a bit more complex, but I hope you get the idea. It basically identifies whether the validator can handle the input supplied. Here are a couple implementations:

public class UrlValidator : IValidator {
    bool CanValidateType(string type) {
        return type.ToLower() == "url";
    }

    bool Validate(string input) {
        /* Validate Url */
    }
}

public class EmailValidator : IValidator {
    bool CanValidateType(string type) {
        return type.ToLower() == "email";
    }

    bool Validate(string input) {
        /* Validate Email */
    }
}

Now you will use constructor injection to inject the dependency into your class:

public class SomeSimpleClass {
    private IValidator validator;

    public SomeComplexClass(IValidator validator) {
        this.validator = validator;
    }

    public void DoSomething(string url) {
        if (validator.CanValidateType("url") && 
            validator.Validate(url))
            /* Do something */
    }
}

The CanValidateType comes in handy when you have a class that can use multiple validators. In this scenario you pass in a list or an array of validators to the constructor.

public class SomeComplexClass {
    private List<IValidator> validators;

    public SomeComplexClass (List<IValidator> validators) {
        this.validators = validators;
    }

    public bool ValidateUrl(string url) {
        foreach (IValidator validator in this.validators)
            if (validator.CanValidateType("url"))
                return validator.Validate(url);
        return false;
    }


    public bool ValidateEmail(string email) {
        foreach (IValidator validator in this.validators)
            if (validator.CanValidateType("email"))
                return validator.Validate(email);
        return false;
    }
}

You would then have to pass in the required instance of the validator(s) to your classes somehow. This is often done with an IoC container (like Castle Windsor) or do it yourself.

IValidator emailValidator = new EmailValidator();
IValidator urlValidator = new UrlValidator();
SomeSimpleClass simple = new SomeSimpleClass(urlValidator);
SomeComplexClass complex = new SomeComplexClass(new List<IValidator> { emailValidator, urlValidator });

The above code gets tedious to do on your own, this is why IoC containers are so handy. With an IoC container you can do something like the following:

SomeSimpleClass simple = container.Resolve<SomeSimpleClass>();
SomeComplexClass complex = container.Resolve<SomeComplexClass();

All the mapping of interfaces is done in your app.config or web.config.

Here's an awesome tutorial on Dependency Injection and The Castle Windsor IoC container.

whatispunk