4

这个比那个好吗？

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

最近有人告诉我，这已经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'.
    }
}

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

4

3 回答 3

3

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

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

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

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

  • 的功能DoSomething与 的职责没有直接关系MyObject。如果你把一个不相关的方法放进去MyObject，它会导致低内聚。
  • MyObject没有执行所需的所有信息DoSomething。如果你给这个额外的信息MyObject，它会导致高耦合。

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

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

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

于 2012-07-25T02:15:15.753 回答
0

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

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

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

于 2012-07-24T20:05:00.757 回答
0

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

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

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

于 2012-07-24T20:49:26.827 回答