扩展类：在类中执行此操作还是使用观察者？
我需要扩展一个类（在 C++ 中，但我认为这个问题与语言无关），其功能可以通过两种不同的方式实现：
- 逻辑简单地添加到类本身
- 通过向类添加观察者逻辑并将 ，然后将观察者中的逻辑，在类之外
这两种选择都有优点和缺点：
- 由于代码也可能用于其他类，因此在观察者中添加逻辑似乎更合乎逻辑。未来的类只需要支持观察者。
- 另一方面，观察者对计算密集型代码的影响很难预见。稍后在代码中添加的新观察者可能会对计算密集型代码产生负面影响。
有没有人明确规定何时在类中添加新功能，而不是将其放在类外的观察者中？
I need to extend a class (in C++, but this question is language-agnostic I think), with functionality that can be implemented in two different ways:
- by simply adding the logic to the class itself
- by adding observer logic to the class and putting the logic in an observer, outside the class
There are advantages and disadvantages in both alternatives:
- since the code might be used for other classes as well, it seems more logical to add the logic in an observer. Future classes then only need to support observers.
- on the other hand, the impact of observers in calculation-intensive code is hard to foresee. New observers added later in the code, might have a negative impact in the calculation-intensive code.
Has anyone clear rules on when to add new functionality within the class, as opposed to putting it in an observer outside the class?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为在这种情况下（就像很多情况一样）——这取决于情况。这是一个了解在您正在解决的问题的背景下什么是合适的情况。
从纯粹的意义上来说，您认为观察者模型将来可能更容易扩展和操作的想法可能是正确的。然而，如果实际上必须在合理的时间范围内开展工作，这种纯粹主义观点很少考虑到务实的现实。
观察者模型很可能很适合你。但逻辑时间是否至关重要，是否可能很昂贵？如果这些事情在您的实施中很重要，那么您必须对它们进行说明。
不幸的是，只有你自己知道——虽然它在一种情况下可能工作得很好，但概念上相似的情况可能有不同的限制，并且在相同的设计下表现不佳（或完全不切实际）。
所以，回答你的问题：不 - 老实说，我认为没有人可以说有明确的规则。
人们可能有偏好，并且它们更适用或大部分适用。但我怀疑它们是否会变得普遍。
你必须考虑一下——但这就是它的乐趣所在！
I think in this case (as with so many) - it depends. It's a case of knowing what's appropriate in in the context of the problem you're addressing.
In a purist sense, you're probably right in thinking that the Observer model is potentially easier to extend and manipulate in the future. However that purist view rarely takes into account the pragmatic realities if actually having to work in a reasonable timescale.
It may well be that the observer model serves you fine. But is the logic time critial, and is it likely to be expensive? If these are things that matter in your implementation, then you have to tale account of them.
Unfortunately, only you can tell - and while it may work well in one situation, a conceptually similar situation may have different constraints, and perform poorly (or be totally impractical) with that same design.
So, in answer to your question: no - I honestly don't think that anyone can say that there are clear rules.
People may have preferences, and they be more, or mostly, applicable. But I doubt they're ever going to be universal.
You're going to have to think about it - but that's what makes it fun!
扩展功能的一种流行方法是扩展接口模式，如上所述在 POSA1 中。
您可能会考虑的另一种模式是代理模式。如果逻辑是离散的，您可以将代理对象相互链接并仅通过接口引用它们。这应该允许您将逻辑很好地分布在几个独立且可互换的对象上。
鉴于我不太了解您的情况，我很难就设计提供更多建议。但我希望这会有所帮助。
A popular way to extend functionality is the Extension Interface pattern, as described in POSA1.
Another pattern you might consider is the Proxy pattern. If the logic is discrete, you can chain proxy objects to each other and solely refer to them through an interface. This should allow you to spread the logic out nicely over several independent and interchangeable objects.
It's kind of hard for me to give more advice on the design, given that I don't know a whole lot about your situation. But I hope this helps.