反模式的名称是什么！string.IsnullOrEmpty(Employee.Name), (Decapsulation ?)

Question

我经常遇到应该在业务对象中的逻辑在各处重复的代码：

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

应该是这样的：

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

Employee.IsNameSpecified 具有指定值的逻辑。

这只是一个例子，我脑海中浮现出许多与 OOP 相反的例子，程序代码用于对业务对象做出逻辑决策。

当 Logic 被封装在 BusinessObject 中时，这只是正常的 OOP 实践（或有不同名称的doeas？），相反的叫什么？解封装？

Answer 1

您的示例不是反模式（并且违反了 MVC 模式）：

1. 您的 Employee 类是模型的一部分。
2. 您的 if 必须在 View 类中。这就是 View 类显示模型层的（一个）元素的作用。
3. 您的方法 IsNameSpecified 用于确定是否必须显示您的员工姓名。

1+2+3 : 你的方法必须在你的视图类中实现。 模型中没有。

因此，按照您的逻辑（以及其他开发人员编写 !string.IsNullOrEmpty 的逻辑），此方法现在位于 View 类中：IsNameSpecific(Employee e)。它的实现将只包含一条指令。人们显然会选择不写这种方法。

@GhostCat : employee.display();显然是一个错误...想象一下，对于此应用程序的特定客户，员工只是一个数字。而对于其他客户，它是一个名称和一个角色......等等......

您的模型的作用只是构建信息。不显示自己。

Answer 2

您可以将其视为TDA 的一种风格（告诉，不要问）。

您在此处执行的操作：客户端代码检索另一个类拥有的“属性”，然后根据该值做出决定。

TDA 准确地暗示了您的问题：other 类应该为您做出该决定 - 您的客户端代码不应该知道做出该决定的规则。

但请注意这里的“递归”：提议的“解决方案”仍然违反 TDA。您仍在从另一个类中获取值，以便客户端代码可以对其做出决定。

唯一的区别：在第一种情况下，您获取一个字符串，客户端检查该字符串是否为空/空；在第二种情况下，您获取一个布尔值，告诉您该做什么。

因此，“理想”的 OO 解决方案更像是：

employee.display();

而员工完全靠自己做正确的事情。但可以肯定的是，这种实现很快就会变成违反 SRP 的例子——员工类真的应该知道“显示”本身吗？！