如果在代理模式中我们有接口而不是代理类中的实际具体主题,则它等效于装饰器模式

nit*_*.kk 5 java design-patterns decorator proxy-pattern

代理模式在进行了一些其他处理(例如应用检查是否需要处理请求还是基于某些凭据检查)之后,将请求委托给Real主题。

它的类图如下

在此处输入图片说明

代理类直接引用了具体的Subject。

装饰器模式丰富了组件的行为(像代理一样,它也进行一些附加处理并将操作委托给实际组件)。此模式的类图类似于Proxy模式,唯一的区别是它具有对组件接口的引用。

在此处输入图片说明

在Proxy类中拥有具体的实际主题会使单元测试变得困难,因为类仅应依赖于接口而不是依赖于实现。我的问题是,如果代理模式也引用了Real主体公开的接口,那么它将等同于Decorator模式。在这种情况下,代理模式的类图也将如下所示

在此处输入图片说明

Dra*_*vic 5

一切都与意图有关。从功能上讲,它们是等效的,但装饰器的要点是向对象动态添加功能,而代理仅控制对目标对象的访问,而无需向其添加任何其他功能。

因此,代理的客户端期望的结果与使用真实对象相同,而装饰器的客户端将其留给装饰器以在将调用委派给目标之前和/或之后执行任何其他逻辑。

因此,从概念上讲,在您的示例中,您似乎仍在处理代理。

  • 存在设计模式以进行组合。您无法使用单一模式来构建任何东西。通常,对书外模式进行修改以适合实际需求(并且需要更改和适应它们,书中模式的实际结构更像是一些基本准则和示例)。例如,AOP代理(事务方法是著名的示例)。他们总是将目标委托给目标,用事务边界等方式装饰方法,但无论如何,代理/拦截器是业界/社区接受的术语。 (4认同)
  • 感谢您的答复和评论。我已经接受了您的回答,并且希望您在回答中添加评论(最后一个),这确实很好,而且非常有帮助。我现在理解应该从问题的角度而不是从解决方案的角度来看模式。我们有一个问题,我们应用良好的OO实践和原则,而解决方案将是其中的一种模式。模式只是帮助我们思考一个方向,但重点应该是解决问题而不是强制执行模式。 (2认同)