2

我经常遇到代码,应该在业务对象中的逻辑在任何地方都重复,如下所示:

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

它应该是这样的:

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

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

这只是一个例子,我想到了许多其他与 OOP 相反的例子,过程代码用于对业务对象做出逻辑决策。

当 Logic 被封装在 BusinessObject 中时,这只是正常的 OOP 实践(或有不同名称的 doeas?),相反的名称是什么?解封装?

4

2 回答 2

2

您可以将其视为TDA的一种风格(告诉,不要问)。

你在这里做什么:客户端代码检索另一个类拥有的“属性”,然后根据该值做出决定。

TDA 确切地暗示了您的问题是什么:其他类应该为您做出该决定 - 您的客户端代码不应该知道做出该决定的规则。

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

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

因此,“理想”的 OO 解决方案更像是:

employee.display();

并且员工完全靠自己做正确的事情。但是可以肯定的是,这个实现很快就会变成违反 SRP 的例子——一个 Employee 类真的应该知道“显示”本身吗?!

于 2016-09-08T10:40:33.320 回答
1

您的示例不是反模式(并且违反了 MVC 模式):

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

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

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

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

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

于 2016-09-13T15:53:47.450 回答