MyObject.DoSomething（）vs MyService.DoSomething（MyObject）

Question

一个比另一个好吗？

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

我最近被告知MyObject.DoSomething()已经过时了，并且这样做的服务方式是首选。是吗？

示例：

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

VS

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

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

Answer 1

  

我最近被告知MyObject.DoSomething()已经过时了，并且这样做的服务方式是首选。是吗？

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

根据经验，你应该首先尝试将它放在班级本身，即MyObject.DoSomething()。

如果出现以下情况，您应该只使用单独的（服务）类

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

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

  

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

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

Answer 2

我认为我认为你使用的第一种方法是围绕主要的OOP主体，如抽象，封装等。

然而，第二种方法是关注设计更改主体，以便更轻松地重建/重新测试和重新部署应用程序，如接口隔离，依赖性反转等。

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

Answer 3

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

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

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