【问题标题】:The single responsibility principle and aggregation单一职责原则和聚合
【发布时间】:2016-07-31 04:27:36
【问题描述】:

我知道单一责任原则指出一个类应该只有一个责任或一个改变的理由。这是否意味着具有许多聚合成员变量的类违反了这一原则?我的意思是当一个类将它的一些操作委托给它的聚合成员变量时是否违反了 SRP?或者这些聚合成员是否被认为只对它们的操作负责,而包含它们的类与这些操作无关?

【问题讨论】:

  • 你所问的具体例子会很有用。
  • 假设您有一个用于视频游戏的 playerCharacter 类。在这个类中,您聚合了 characterAi、characterAnimation 和 characterController 的成员。我只是想确认,即使 playerCharacter 类具有所有这些聚合成员,仅此一项并不违反 srp。
  • 确实如此。但是如果 playerCharacter 构造 characterAi、characterAnimation 和 characterController 并使用它们,那么你对 playerCharacter 的要求就有点高了。
  • 好的。是的,我很好奇,因为在我看来,您需要在类之间进行一些交互,以使您的主程序尽可能具有可读性。如果您有大量单独的小类,我觉得当您必须将所有这些类带入并连接它们时,这会降低 main 的可读性。
  • 你可以拥有大量独立的小类,但仍然有一个相当干净的主类。一种模式是构造在 main 中应该有一个实例的所有对象。将它们相互传递并构建对象图。如果这变得很长,请开始抽象构造。然后在一个对象上调用一个方法来启动整个工作。

标签: c++ aggregation single-responsibility-principle


【解决方案1】:

课程有多少不是重点。这是班级所做的。这是为了什么。它的责任是什么。该类可能不会公开任何这些聚合成员。它可能只有一种方法。所有这些成员都需要完成这项工作。只要有一份工作就不会违反单一职责原则。

也就是说,有可能在一项工作下过度扁平化,而这些工作应该在其他职责下进行分组和抽象。如果这些抽象职责的变化影响了我们的类,那么它们就没有被正确地抽象出来。

对一个对象的引用应该只会让你看到它的接口。不是它的内部变化。

【讨论】:

  • 好的,这有点清楚了。非常感谢。
猜你喜欢
  • 1970-01-01
  • 2010-11-26
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2022-11-09
  • 2016-01-21
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多