Как вы тестируете бизнес-правило, когда оно доступно для свойства? - PullRequest
2 голосов
/ 08 февраля 2011

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

Мои первые мысли о реализации этого поля как свойства и определении сеттера как защищенного, не позволяющего пользователям использовать (и устанавливать) егопосле того, как объект создан.Но, подумав некоторое время, я заставил меня украсть бизнес-правило в правиле доступности свойств.

Моя вторая мысль состояла в том, чтобы оставить настройщик свойств открытым, внедрить исключение при его установке, что делает бизнес-правило довольно явным.Будет контрольный пример, в котором свойство будет выдавать исключение каждый раз, когда кто-то пытается его установить.

Что ж, но это много шаблонов, чтобы избежать поведения, почему бы не сделать его защищенным в конце концов,избегая даже неправильного использования в других частях кода?Но потом я подумал: а что, если другой разработчик случайно изменит доступность свойства и снова сделает его публичным, а пользователи бизнес-объекта начнут использовать это поле, нарушая бизнес-правило?

Каков наилучший подход в этой ситуации?Как бы вы решили эту проблему?

1 Ответ

3 голосов
/ 08 февраля 2011

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

public class SomeClass
{
  public SomeClass(DateTime regDate)
  {
     registerDate = regDate;
  }

  public DateTime RegisterDate { get { return registerDate; } }

  private readonly DateTime registerDate;
}
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...