несколько классов с теми же методами - лучший шаблон

Создайте Электронное письмо как отдельный класс.
Используйте адрес электронной почты в качестве свойств / параметров / возвращаемых значений в ваших классах вместо String .
Создайте EmailValidator для проверки строк как адресов электронной почты.
Создайте EmailFactory , который возвращает сообщение электронной почты при передаче действительного адреса электронной почты и null в противном случае.

(Сделайте то же самое для веб-сайта).

Вам действительно нужно хорошенько изучить методологию аспектно-ориентированного программирования (AoP). В Enterprise Library 4.1 есть реализация AoP под названием Unity Interception.

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

Эта структура позволяет вам кодировать единственный класс обработчика для проверки электронной почты. Это влечет за собой то, что код проверки переходит в класс обработчика и больше не является частью класса (ов). Следующее, что вам нужно сделать, это отметить классы для перехвата.

Вы можете перехватить классы различными способами, включая установку атрибута для желаемого метода, который должен быть перехвачен и обработан в соответствии с вашими требованиями. Установка атрибута, вероятно, является самым простым способом перехвата.

Похоже, вам просто нужен статический класс со статическим методом

public static class Utilities{
    public static bool validEmail(string email)
    {
        //Your code here
    }
}

Создайте служебный класс и определите эти методы как методы расширения для соответствующего класса / интерфейсов.

Я бы порекомендовал вам создать интерфейс IValidator, а затем создать несколько разных валидаторов, которые обрабатывают разные сценарии. Вот один пример:

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

Метод CanValidateType () мог бы быть немного сложнее, но я надеюсь, что вы уловили идею. Он в основном определяет, может ли валидатор обрабатывать предоставленный ввод. Вот пара реализаций:

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 */
    }
}

Теперь вы будете использовать внедрение конструктора для внедрения зависимости в ваш класс:

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 */
    }
}

CanValidateType пригодится, когда у вас есть класс, который может использовать несколько валидаторов. В этом сценарии вы передаете конструктору список или массив валидаторов.

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;
    }
}

Затем вам нужно будет каким-то образом передать требуемый экземпляр валидатора (ов) вашим классам. Это часто делается с помощью контейнера IoC (например, Castle Windsor) или выполняется самостоятельно.

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

Приведенный выше код становится утомительно выполнять самостоятельно, поэтому контейнеры IoC так удобны. С контейнером IoC вы можете сделать что-то вроде следующего:

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

Все отображение интерфейсов выполняется в вашем app.config или web.config.

Вот отличный учебник по внедрению зависимостей и контейнеру IoC Castle Windsor.

создать классы и интерфейсы логики проверки и внедрить их в ваш код ... поэтому отделите логику от проверки, чтобы ее можно было использовать повторно ...

Да, дублирование этого кода было бы неприятным запахом, вы можете извлечь эти методы в один класс Helper в статических методах или вы можете определить класс интерфейса «Validator» и использовать этот интерфейс , вы можете связать различные методы проверки с шаблоном цепочки ответственности.

Вы можете поместить весь код проверки в класс Validator, а затем использовать этот класс везде, где выполняется проверка нужный. Доступ к проверке должен осуществляться одним методом, возможно Validate (object Something) . Я думаю, что это называется «Композиция» (что касается шаблонов проектирования).

Позже у вас могут быть подклассы Validator, которые могут быть более конкретными или выполнять различные виды проверки.

Вы также можете сделать так, чтобы все классы, требующие проверки, расширяли базовый класс или абстрактный класс, в котором содержится 90% проверки.