让我们说我有一个名为send_welcome_email()
的函数和一个名为User
的类(在Python中实现,但希望非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
类耦合。
我知道这是一个已知的反模式,但我找不到它。有谁知道它叫什么?
答案 0 :(得分:2)
我认为反模式没有名称,但违反此规则的规则称为Law of Demeter。
LoD可以被视为假设“最少结构知识”的原则(其创造者称之为“结构害羞编程”)。我们的想法是假设除了你自己的直接自我之外没有任何对象的内部结构。
我听到它描述的方式:在商店里,如果你付钱给收银员,你会从钱包里拿出你的信用卡并交给他们,而不是交出钱包让他们翻找它。你的例子显示了翻找方法;该函数获取User对象,它必须知道如何访问email属性,它不应该知道。
答案 1 :(得分:1)
该功能只有the Feature Envy code smell。 (“Code smells”是反模式,由Fowler和Beck在the Refactoring book中的一章中记录,在“反模式”这个词被广泛使用之前命名。)功能Envy是指一个模块通过调用耦合到另一个模块的时候许多其他模块的方法。在这种情况下,一个太多了。
通常的解决方法是将方法提取到另一个模块上,但这不适用于此处,因为只有一个臭方法调用。要求函数调用者调用方法的修复工作只要调用者能够与if (user_id == some_value) {
<select class="form-control" disabled>
<option><?=$user['User']['username'];?><option>
</select>
} else {
<select class="form-control">
<option><?=$user['User']['username'];?><option>
</select>
}
类进行耦合就可以了。
这确实提醒了Law of Demeter之一,这是一个减少耦合的指南,但这最适用于调用者调用另一个方法调用方法的调用者,这在这里没有发生。
答案 2 :(得分:0)
听起来像Anemic Domain Model。
答案 3 :(得分:0)
send_welcome_email
的目的不是为了欢迎用户的特定目的而生成电子邮件(我需要有关用户的信息,如姓名,用户名,电子邮件地址)?
您的替代方案不会这样做。
该方法可能不应该在用户类中,而是类似UserEmailSender
或类似的东西。
我的答案是否定的:它看起来不像反模式。