Что такое название антипаттерн string.IsnullOrEmpty (Employee.Name),

Question

Очень часто я сталкиваюсь с кодом, что логика, которая должна быть в пределах бизнес-объекта повторяется везде как таковой! (Декапсуляция?):

if (!string.IsNullOrEmpty(Employee.Name)) Display(Employee.Name); 

где, как это должно быть так:

if (Employee.IsNameSpecified) Display(Employee.Name); 

и Employee.IsNameSpecified имеет логику значения уточняются.

Это только один пример, многие другие приходят на ум, обратные ООП, процедурный код используется для принятия логических решений о бизнес-объектах.

Когда логика инкапсулирована в BusinessObject, то это обычная практика ООП (или у других есть другое имя?), Что называется обратным? Декапсуляция?

Answer 1

Вы можете видеть это как один аромат TDA (расскажите, не спрашивайте).

Что вы здесь делаете: клиентский код извлекает «свойство», принадлежащее другому классу, чтобы затем принять решение на основе этого значения.

TDA подразумевает, что именно ваш вопрос: другой класс должен принять это решение для вас - ваш код клиента не должен знать правила для принятия такого решения.

Но обратите внимание на «рекурсию» здесь: предлагаемое «решение» по-прежнему нарушает TDA. Вы еще извлекаете значение из другого класса, чтобы клиентский код мог принять на него решение.

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

Таким образом, «идеальное» OO решение будет больше похоже:

employee.display(); 

и работник полностью делает правильную вещь самих по себе. Но, конечно, эта реализация может быстро превратиться в нарушение SRP, например, если класс Employee действительно знает о «отображении» себя ?!

Answer 2

Ваш пример не является анти-модель (и нарушает шаблон MVC):

1. Ваш класс Employee является частью вашей модели.
2. Ваш должен быть в классе вида. И это роль класса View для отображения (ов) элемента (ов) уровня модели.
3. Ваш метод IsNameSpecified используется здесь, чтобы определить, должно ли отображаться имя вашего сотрудника.

1 + 2 + 3: ваш метод должен быть реализован в вашем классе вида. Не в модели.

Итак, следуя вашей логике (и тем, что другие разработчики пишут! String.IsNullOrEmpty), этот метод теперь находится в классе вида: IsNameSpecific (Employee e). И его реализация будет содержать только одну инструкцию.Люди явно не захотят писать такой метод.

@GhostCat: employee.display(); очевидно ошибка ... Представьте себе случай, когда для конкретного клиента этого приложения работник - всего лишь номер. И для другого клиента это имя и роль ... И так далее ...

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