6
如何避免在次优设计中无休止地迭代？
因此，可能像许多人一样，我经常发现自己对设计问题感到头疼，例如，有些设计模式/方法似乎可以直观地解决问题并具有预期的好处。通常会有一些警告，如果没有某种工作就很难实施模式/方法，而这周围的工作否定了模式/方法的好处。我可以很轻松地结束许多模式/方法的迭代，因为可以预见的是，几乎所有的模式/方法在现实世界中都存在一些非常重要的警告，在这些情况下，根本没有一个简单的解决方案。 例： 我将给您一个假设的示例，大致基于我最近遇到的一个真实示例。假设我想在继承上使用合成，因为过去继承层次结构阻碍了代码的可伸缩性。我可能会重构代码，但随后发现在某些上下文中，超类/基类只是需要在子类上调用功能，尽管尝试避免这样做。 下一个最好的方法似乎是实现一半委托/观察者模式和一半组合模式，以便超类可以委托行为，或者子类可以观察超类事件。然后，该类的可伸缩性和可维护性较差，因为它不清楚应如何扩展，而且扩展现有的侦听器/代理也很棘手。同样，信息也隐藏得不好，因为人们开始需要了解实现以了解如何扩展超类（除非您非常广泛地使用注释）。 因此，在此之后，我可能会选择完全使用观察者或委托人来避免因混淆大量方法而带来的弊端。但是，这有其自身的问题。例如，我可能会发现我最终需要观察者或代表来应对越来越多的行为，直到我几乎需要针对每种行为的观察者/代表。一种选择可能是只为所有行为提供一个大的侦听器/代理，但是实现类最终会带有许多空方法等。 然后，我可以尝试另一种方法，但是与此同时存在很多问题。然后是下一个，然后是下一个，依此类推。 当每种方法似乎都存在其他问题时，这种迭代过程将非常困难，并导致某种设计决策瘫痪。无论使用哪种设计模式或方法，都很难接受代码最终同样会带来问题。如果我最终陷入这种情况，是否意味着问题本身需要重新考虑？别人遇到这种情况时会做什么？ 编辑： 似乎有一些我想清除的问题的解释： 我将OOP完全排除在问题之外，因为事实证明它实际上并不是特定于OOP的，而且很容易误解我在传递OOP时所做的一些评论。 有些人声称我应该采取迭代的方法并尝试不同的模式，或者当它停止工作时我应该放弃一个模式。这是我首先要参考的过程。我认为这个例子很清楚，但是我可以更清楚一点，所以我编辑了问题。