Что это за анти-шаблон?

Question

Скажем, у меня есть функция под названием send_welcome_email() и класс под названием User (реализованный в Python, но, надеюсь, легко понять, для разработчиков непитоновские):

class User: 
    email = TextField() 
    first_name = TextField() 
    last_name = TextField() 


def send_welcome_email(user): 
    msg = EmailMessage(recipient=user.email) 
    msg.send() 

В этом случае, было бы лучше, чтобы определить интерфейс функции как:

def send_welcome_email(email) 

так что функция не связана с User класса.

Я знаю, что это известный анти-шаблон, но я не могу его найти. Кто-нибудь знает, как это называется?

Answer 1

Я не думаю, что есть имя для анти-шаблона, но правило, что это является нарушением, называется Law of Demeter.

LoD можно рассматривать как принцип принятия «наименее структурных знаний» (что-то его создатель называет «структурно-застенчивым программированием»). Идея состоит в том, чтобы предположить знание внутренней структуры объекта, кроме вашего собственного непосредственного Я.

Как я слышал, он описал: в магазине, если вы платите кассир вы получите вашу кредитную карту с вашего кошелька и дать им, а не сдать бумажник и позволить им рыться через него. Ваш пример показывает подход к рывке; функция получает объект User, и она должна знать, как получить доступ к свойству электронной почты, о котором ему не нужно знать.

Answer 2

Звучит как Anemic Domain Model.

Answer 3

Разве не цель send_welcome_email генерировать электронное письмо с целью приветствовать пользователя (мне нужна информация о пользователе, например, имя, имя пользователя, адрес электронной почты)?

Ваша альтернатива не делает этого.

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

Таким образом, мой ответ отрицательный: он не похож на анти-шаблон.

Answer 4

Функция имеет the Feature Envy code smell. («Запахи кода» - это антипаттерны, задокументированные в главе Фаулера и Бек в the Refactoring book, названных до того, как слово «антипаттерн» было широко использовано.) Особенность Зависть - это когда один модуль связан с другим модулем, вызывая слишком много других модульных методов. В этом случае слишком много.

Обычное исправление заключается в извлечении метода на другой модуль, но это не применяется здесь, так как есть только один вызов вонючего метода. Исправление запроса вызывающего абонента функции для вызова метода работает до тех пор, пока это нормально, когда вызывающий абонент имеет эту связь с классом User.

Это напоминает один из Law of Demeter, руководство, которое уменьшает сцепление, но наиболее точно относится к вызывающему абоненту, вызывающему метод по результату вызова другого метода, чего здесь не происходит.