java – 代理模式与重写
|
假设有一个接口Subject.
interface Subject { void request(); }
我们有一个RealSubject类.假设我们想要增强RealSubject,我们可以使用包裹RealSubject的代理模式： class Proxy implements Subject {
private RealSubject ref;
void request(){ ... }
}
或者我们可以扩展RealSubject并覆盖该方法 class EnhancedSubject extends RealSubject {
@Override
void request() { ... }
}
哪种方法更好？我知道Liskov原则;让我们假设EnhancedSubject满足Liskov原则.你还在考虑继承吗？ 如果没有接口Subject(即,RealSubject没有实现任何接口),似乎“inherit and override”是唯一的选项,因为在Proxy模式中没有要实现的接口.如果没有主题界面,您仍然可以应用代理模式吗？ 解决方法
在回答你的第一个问题时,“哪种方法更好”？
我个人更喜欢使用接口和代理(或装饰器)模式来实现这样的东西. (参见：第16项：赞成组合而非继承Effective Java (2nd Edition)) 如果超类(RealSubject)不在您的控制之下,即在同一个包中,并且专门为Extension设计和记录,那么从实现到版本的任何实现的更改都可能会破坏子类的实现(EnhancedSubject).基本上我所说的是：直接根据具体实现导致脆弱的代码. 在回答你的第二个问题时,“如果EnhancedSubject满足Liskov原则,你还会考虑继承吗？” 如果RealSubject和EnhancedSubject在您的控制之下并以相同的生命周期发布,则再次使用继承是安全的,但直接根据具体实现导致脆弱的代码. 希望能够让您使用Interface实现的另一点是Unit 例如,使用您希望应用单元测试的情况,将RealSubject的模拟依赖项注入到Subject的Proxy实现中会更容易,这样您就可以专门测试Proxy类,而不必完全测试整个对象层次结构,RealSubject和EnhancedSubject,只是为了确认EnhancedSubject的行为符合预期. 我想可以这么说,如果它是一个非常简单的API并且将来几乎不会改变,那么具体实现就更简单了.并保持简单愚蠢(K.I.S.S.)是最好的政策之一. “如果没有主题界面,你还可以申请代理模式吗？”您可以将RealSubject注入另一个类并在内部使用RealSubject,但如果使用RealSubject的API直接依赖于具体类,则您没有其他选择,只能使用继承. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |