Вопросы Теги

Как Вы улучшили бы этот простой класс, который будет более слабо связан?

У вас есть «» в недопустимом месте выражения «когда». Это должно быть так: 

    msg: "{{ item }} is not defined"
 when: "{{ item }} is not defined"

Таким образом, результат будет: 

failed: [hostname] (item=street) => {"changed": false, "item": "street", "msg": "street is not defined"}
6
задан Cory House 8 December 2008 в 03:55
поделиться

2 ответа

Предложения до сих пор все, кажется, путь излишество, особенно со всем МОК и материалом AOP.

  1. User классу нужен адрес электронной почты, поэтому создайте EmailAddress класс и имеет User класс принимает один через свойство и/или его конструктора. Та проверка может быть столь же простой как ли вход EmailAddress ссылка является нулевой или нет.

  2. EmailAddress класс может быть простой, но обычно допускающей повторное использование реализацией (рассмотрите базирование его на документе RFC). Это должно быть неизменно и должно выдать исключение от своего конструктора на недопустимом входе.

  3. Идеально, EmailAddress класс должен состоять из EmailUserId класс (на основе RFC?) и a InternetDomain класс (на основе RFC?), так как адрес электронной почты является составной структурой данных. Снова, каждый из тех классов должен управлять неизменными экземплярами и должен выдать исключение на конструкции с недопустимым входом.

"Проверка" кажется мне не "вещью", а скорее универсальным "действием". Поэтому это предоставляет себя тому, чтобы быть методом, а не классом. В этом случае я склонен реализовывать проверку в каждом из этих классов как частный статический метод (valid(input)) это вызывается от конструктора на языках как Java или C#. Часто, становится полезно выставить ту функциональность публично в форме вопроса (isValid(input)).

Править:

Вы предлагаете, чтобы каждый отличный тип данных, который я должен проверить, имел свой собственный класс?

Это - один твердый способ решить проблему, обычно известную как Тип Значения (спасибо за напоминание, Frank). Результат будет некоторыми (дюжина или два) четко определенные, допускающие повторное использование классы как, возможно, EmailAddress, PhoneNumber, PersonName, и т.д. Представленная альтернатива, вероятно, приведет к "классу бога" со смесью функциональности, которая не является допускающей повторное использование, не легкой протестировать, и трудный поддержать.

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

10
ответ дан 9 December 2019 в 22:41
поделиться

Я был бы:

  1. Повредите связь с конкретным объектом Проверки через внедрение зависимости: определите краткий обзор (чистый виртуальный) класс Проверки, заставьте конкретный класс проверки произойти из него, и передача во ("вводит") ссылку на абстрактный класс Проверки в Пользовательском конструкторе класса.

    Для превосходного обсуждения как и почему сделать это в C++, см. статью Robert Martin 1996 года о предмете из Отчета C++.

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

1
ответ дан 9 December 2019 в 22:41
поделиться