MyObject.DoSomething() 与 MyService.DoSomething(MyObject)答案

【问题标题】：MyObject.DoSomething() vs MyService.DoSomething(MyObject)MyObject.DoSomething() 与 MyService.DoSomething(MyObject)
【发布时间】：2012-07-23 05:05:16
【问题描述】：

一个比另一个更好吗？

这甚至是一个有效的问题吗？

最近有人告诉我，MyObject.DoSomething() 已经过时了，而且这种服务方式是首选。对吗？

例子：

public class Policy : ICancellable
{
    public void Cancel()
    {
        // Code to cancel working with 'this'.
    }
}

对

public class PolicyCancellationService
{
    public void Cancel(Policy policy)
    {
        // Code to cancel working with 'policy'.
    }
}

如果使用服务方式 - 对象可以负责任何功能还是应该只是愚蠢的？

【问题讨论】：

标签： oop service domain-driven-design orchestration

【解决方案1】：

最近有人告诉我，MyObject.DoSomething() 已经过时了，而且这种服务方式是首选。对吗？

两种方式都有效；你应该选择导致高内聚和低耦合的那个。

根据经验，您应该首先尝试将其放入类本身，即MyObject.DoSomething()。

您应该只在以下情况下使用单独的（服务）类：

DoSomething 的功能与MyObject 的职责没有直接关系。如果将不相关的方法放入MyObject，会导致内聚力低。
MyObject 没有执行 DoSomething 所需的所有信息。如果将此附加信息提供给MyObject，则会导致高耦合。

在您的示例中，如果取消是策略的一个重要功能，并且该策略具有执行此操作所需的所有信息，则应将其保留在 Policy 类中。

如果使用服务方式 - 对象可以负责任何功能还是应该只是愚蠢的？

恰恰相反：您应该在域对象本身中保留尽可能多的功能。服务应该仅限于协调多个领域对象之间的活动；它们最好不包含任何业务逻辑。

【讨论】：

【解决方案2】：

也许将其称为Service 的最重要的论点是进程间通信往往很慢，这通常是使用服务的意思。如果管理不当，可能会导致chatty interfaces 性能不佳。

因此，明确地对该边界建模是很好的，这将使人们意识到调用外部服务时可能出现的问题，因此他们将更好地决定何时调用该服务。

现在如果逻辑没有外部依赖，我可能会把它留在对象中，而不是完全称它为“服务”。

【讨论】：

【解决方案3】：

在我看来，您使用的第一种方法是围绕 OOP 的主要原则，如抽象、封装等。

但是，第二种方法侧重于设计更改原则，以便更轻松地重新构建/重新测试和重新部署应用程序，例如接口隔离、依赖倒置等。

在我看来，没有过时的方法是首选的方法。

【讨论】：