Нужна помощь в моделировании классов

Question

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

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

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

подход один: создать новый класс:

class ValidatePerson {} 

и класс имеют методы: «validateAge()» и «validateName()» и каждый vallidation, что мне нужно, я буду иметь для внедрения нового метода.

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

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

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

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

Answer 1

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

Вариант 1 Person класс имеет метод vailidate(), который вы можете позвонить, чтобы выполнить все, что он Validations на его текущем состоянии.

Pros

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

Против

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

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

Pros

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

Cons

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

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

Pros

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

Против

• Может быть излишним в некоторых сценариях

---

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