当界面迫使我违反单一责任原则时该怎么办？

Question

(我必须发布的代码很大，我将继续只使用函数名)

我目前在我的项目中面临以下问题:我有一个“来自这个框架的每个模块都可以有一个用户用来控制其行为的小视图”视图容器。

基本上，每个模块都可以在列表中有一个可视点，用户可以点击并查看他们可以使用该模块做什么，问题是，我的模块都尊重ModuleInterface接口，因此系统知道它们实际上是一个模块，每个模块必须遵守以下内容：

shouldItLoad, loadModule, getModuleName, getStartingAction, getPriority所有这些都是必需的，听起来它做了很多事情，但这是必须的，但是我仍然觉得如果我在这个基础上添加更多，我最终会得到一个做得太多的对象。

现在，我希望每个想在视图容器上的对象也尊重ViewBlock接口，这个接口本身就有几个函数，只是为了让我的系统能够摄取它们并创建这个视图。

我们现在至少有9-10个函数，这样我就能让它开始工作了。读起来很糟糕，最重要的是，它做了很多事情，但是：

1. 模块的工作仍然是为其视图定义其参数，而不是其他东西。
2. 如果我选择传递一个可重用的ViewBlockObject，然后我的Module将数据设置为它，并将它摄取并保存，那么我仍然有很多开销，不是说现在**我不能强制执行一个契约(因为我需要将我的ViewBlockObject保存在Module中的一个变量中)。

这里的解决方案是什么？我如何使每个Module具有每个想要有视图的行为必须得到尊重，而不覆盖Module对象本身？

Answer 1

答案很简单:在模块中加入所有模块必须提供的功能，不是更多，也不是更少。

单一责任原则并不意味着一个类只做一件事。一劳永逸是一个不同的原则，主要适用于函数。SRP只说应该有一个改变的理由，因为鲍勃叔叔，这个原则的发明者，解释自己 (和他的门徒确认)。这两个原则都是常常误入歧途，有时会导致过度工程.因此，在将来发生变化的情况下，从衔接和耦合的角度来考虑这一原则。所以更多的是关于改变的因果责任，而不是类本身的责任

不过，您应该看看的另一个原则是界面偏析原理。您确定您的接口所承诺的所有功能都与所有模块相关吗？

Answer 2

当感觉有太多的方法时，需要考虑的原则是低耦合。

坚实的原则并不是唯一的原则。请尊重健全的原则，没有出色的公众演讲者支持他们。

我首先要把你记在shouldItLoad上。算了你不介意吧？告诉我是时候装货了，如果我想的话我会装的。如果有什么需要告诉我的话，告诉我什么，我会告诉你。你只是担心告诉我什么时候。

下面这样的告诉--不要--这样问可能有助于简化您的界面。没有什么比控制狂更复杂的界面了，它必须知道发生了什么事情的每一个细节。不，把细节推开，做些别的事情来处理它们。

与之类似，不如向getStartingAction询问一下，当该开始时，只需调用start如何？另外，确保您有一个很好的理由，不要总是在start之后立即使用load。

Answer 3

如果您觉得实现接口的类比在单个类中做得更多，那么仍然可以将您认为属于的东西分离到单独的类中。

然后，实现接口的单个类可以组成这些类。它包含这些类的实例，只需将对外部方法的调用重定向到这些类。

我对多个类如何与同一个接口的所有相同成员交互感兴趣。我不能说没有看到它，但这暗示了一些空间来重构依赖于接口的类。有一个方法与所有这些依赖项交互吗？如果不是，该方法看起来很像重复的代码吗？

或者，在依赖于接口的类中，不同的公共方法是否不重叠地使用接口的不同成员？在这种情况下，也许它们可以或者应该是单独的类。使用不同的接口成员可能意味着该类中的方法正在做不同的事情。

如果是后一种情况，则可能导致类只使用一些接口成员，从而导致隔离接口，从而解决了原来的问题。