Нужна помощь с занятиями по моделированию - PullRequest
0 голосов
/ 25 ноября 2010

Я изучаю некоторые концепции ОО, такие как шаблоны проектирования, чистый код и некоторые другие вещи, и у меня все еще есть некоторые сомнения относительно того, как действовать дальше.Например, давайте посмотрим на мой пример.

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

У меня есть два подхода, но я не знаю, какой из них мне следует использовать.

Подход первый: я создаю новый класс с именем:

class ValidatePerson {}

, и у класса есть методы: "validateAge ()" и "validateName ()" и каждое утверждение, которое мне нужномне нужно будет реализовать новый метод.

Подход второй: я создаю абстрактный класс: ValidatePerson {}, который будет иметь несколько методов commum для всей проверки, и я получу:

class ValidatePersonAge extends ValidatePerson { validate();} 
class ValidatePersonName extends ValidatePerson {validate();} 

Я хочу выбрать второй подход, потому что каждое новое правило проверки, которое мне придется добавить, будет новым классом и не повлияет на другие.Например, если мне нужно изменить что-то в методе commum для нового правила, я могу просто перезаписать его.При первом подходе мне нужно было бы добавить другой метод, а затем создать другой метод или изменить тот, который уже работает для других, что могло бы привести к сбою.

Дело в том, что я отчасти путаюсь со всемиэто, так как я новичок в программировании, и я хотел бы видеть некоторую помощь и объяснение по этому поводу.Я также читал, что классы должны быть закрыты для изменения, но открыты для расширения (или что-то подобное).

1 Ответ

1 голос
/ 25 ноября 2010

Нет конкретного правильного ответа.Дизайн всегда должен быть в контексте вашей проблемной области и бизнес-контекста.Итак, вот различные варианты

Опция 1 Класс Person имеет метод vailidate (), который можно вызывать для выполнения всех проверок текущего состояния.

Pros

  • улучшенная инкапсуляция
  • изменения локализованы для одного отдельного класса
  • проверка выполняется после установки всех свойств

Минусы

  • Человек может находиться в недопустимом состоянии до вызова метода validate (), следовательно, не может быть сбоя быстро
  • Не может быть разных правил проверки для другого контекста

Вариант 2 Каждое свойство имеет собственный метод validateXXX () в классе Person.Каждый метод setXXX () будет вызывать соответствующий метод validateXXX ().

Плюсы

  • улучшенная инкапсуляция
  • изменения локализованы в 1 отдельном классе
  • Сбой быстрого поведения, т. Е. Объект Person никогда не будет недопустимым состоянием

Минусы

  • может быть излишним в зависимости от контекста
  • Не может иметьразные правила проверки для другого контекста

Вариант 3 Вы можете иметь PersonBuilder, который содержит эти проверки проверки.Построитель выполнит эти проверки до того, как построит объект Person.Таким образом, после создания объекта Person он удовлетворяет всем валидациям и инвариантам.

Pros

  • Вы вышли на валидацию валидаций в класс построителя, поэтому у вас могут быть разные правила валидации дляразличные контексты
  • Логика построения отделена от объекта домена
  • Класс Person можно сделать неизменным после его создания

Минусы

  • Могуществобыть избыточным в некоторых сценариях

Ваш вариант 2 неверен, поскольку ValidatePersonAge НЕ совпадает с ValidatePerson.Вы не подтверждаете человека полностью, а только подтверждаете его возраст.Так что они семантически разные.

...