Question

我已经阅读了几本书并听取了有关软件设计的讲座。但我不知道如何解决因遵循OO设计原则而引起的问题。

这是一些情况。我开始设计简单的单一类（ClassA）。在那之后，ClassA成长起来，承担着类似的责任。根据Single Responsibility Priciple，我从ClassA到ClassB提取了一些逻辑。 ClassA再次变得简单。但是，ClassA的责任可能类似于ClassB的责任，以便ClassA和ClassB相互引用作为成员字段或属性进行合作。换句话说，分类会带来另一种复杂性。这是分离的类之间的交互。 Fromafter，ClassA和ClassB中的每一个也可能在更复杂的责任下成长，某些类（ClassC或ClassD）可以与ClassA或ClassB分开。现在，类之间的交互变得更加复杂。每个类都可以引用其他类作为memeber字段或方法参数。

随着单个类变得更简单，类的数量增加，关系的复杂性和类之间的交互也增加。

在一些幸运的情况下，它可以通过设计模式来解决。然而，在许多情况下，类的分离使类的关系更复杂。并且倾向于生成具有对其他类的过多引用的类作为成员。作为成员的其他类的引用太多的类很难测试。

我已阅读了几本OO设计书籍。大多数人都说简单的课程很好。但是，它们都没有关注由SRP引起的类交互的复杂性。

我错过了什么吗？我该如何解决这个问题？

Answer 1

责任意味着改变的一个原因。

由于某种原因，您可能需要更改A类，并且您可能会意外地更改A类中其他职责的行为。有时您只需要A类功能之一来使用或测试，但您需要创建一个完整的A类。

如果你没有将A类分为A，B，C和D类，责任之间的相互作用仍然存在但隐藏在A类中。

为了让课程更加连贯，更明确的交互会使您的代码更易于维护。

Answer 2

我认为在课堂规模方面考虑srp并不好。我认为你应该考虑演员和改变的理由。

演员是想要改变你的班级的角色。例如，如果您有这样的类：

class User
{
  public function calculatePay()
  public function save()

}

两个不同的角色想要改变你的班级。例如，会计师想要更改calculatePay方法，而DB管理员则希望更改save（）方法。这个课程可能会因为两个不同的原因而改变。

我认为最好将srp视为“将出于同样原因而变化的事物分组在一起”。

单一责任原则的弊端

2 个答案: