我正在查看代理模式,对我来说,它看起来非常像装饰器、适配器和桥接模式。我是不是误解了什么?有什么不同?为什么我要使用代理模式而不是其他模式?在过去的实际项目中,您是如何使用它们的?


当前回答

在许多GoF模式中有大量的重叠。它们都建立在多态性的力量之上,有时只是意图不同。(战略vs.国家)

在阅读了头部优先设计模式之后,我对模式的理解增加了100倍。

我强烈推荐!

其他回答

正如Bill的回答所说,它们的用例是不同的。

它们的结构也是如此。

Proxy and Decorator both have the same interface as their wrapped types, but the proxy creates an instance under the hood, whereas the decorator takes an instance in the constructor. Adapter and Facade both have a different interface than what they wrap. But the adapter derives from an existing interface, whereas the facade creates a new interface. Bridge and Adapter both point at an existing type. But the bridge will point at an abstract type, and the adapter might point to a concrete type. The bridge will allow you to pair the implementation at runtime, whereas the adapter usually won't.

在使用web服务时,我经常使用它。代理模式可能应该重命名为更实用的东西,比如“包装器模式”。我也有一个库,是一个代理到MS Excel。它使自动化Excel变得非常容易,而不必担心背景细节,如安装了什么版本(如果有的话)。

代理、装饰器、适配器和桥接器都是“包装”类的变体。但它们的用途不同。

Proxy could be used when you want to lazy-instantiate an object, or hide the fact that you're calling a remote service, or control access to the object. Decorator is also called "Smart Proxy." This is used when you want to add functionality to an object, but not by extending that object's type. This allows you to do so at runtime. Adapter is used when you have an abstract interface, and you want to map that interface to another object which has similar functional role, but a different interface. Bridge is very similar to Adapter, but we call it Bridge when you define both the abstract interface and the underlying implementation. I.e. you're not adapting to some legacy or third-party code, you're the designer of all the code but you need to be able to swap out different implementations. Facade is a higher-level (read: simpler) interface to a subsystem of one or more classes. Suppose you have a complex concept that requires multiple objects to represent. Making changes to that set of objects is confusing, because you don't always know which object has the method you need to call. That's the time to write a Facade that provides high-level methods for all the complex operations you can do to the collection of objects. Example: a Domain Model for a school section, with methods like countStudents(), reportAttendance(), assignSubstituteTeacher(), and so on.

这是引用自 头部优先的设计模式

定义属于书。例子属于我。

装饰器——不改变界面,但增加了责任。假设你有一个汽车界面, 当您为不同型号的汽车(s, sv, sl)实现此功能时,您可能需要为某些型号添加更多的职责。比如有天窗,安全气囊等。

适配器—将一个接口转换为另一个接口。你有一个汽车界面,你想让它像吉普车一样工作。所以你把车开过来,改装成吉普车。因为这不是真正的吉普车。但它就像一辆吉普车。

Facade -使界面更简单。假设你有汽车、飞机、轮船接口。实际上,你所需要的只是一个将人从一个位置发送到另一个位置的类。你想让门面决定用什么车。然后将所有这些接口引用收集到一个保护伞下,并让它决定/委托以保持简单。

首先:“facade不仅简化了接口,还将客户端与子系统解耦 的组件。 外观和适配器可以包装多个类,但是外观的目的是简化 适配器的作用是将接口转换为不同的东西。”

Design pattern is not mathematics, it is combination of art and software engineering. There is nothing like for this requirment you have to use proxy, bridge etc. Design patterns are created to solve the problems. If you anticipate a design problem, then use it. Based on experience, you will come to know for specific problem, which pattern to use. If you are good in solid design principles, you would have implemented design pattern without knowing it is pattern. Common example is statergy and factory patterns

因此,更多地集中在坚实的设计原则,干净的编码原则和ttd