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直接依赖于具体类,则您没有其他选择,只能使用继承.

标签：dynamic-proxy,java,design-patterns
来源： https://codeday.me/bug/20190730/1581098.html