我在看代理模式，对我而言，它似乎很像装饰器，适配器和桥模式。我误会了什么吗？有什么不同？为什么我会使用Proxy模式而不是其他模式？你过去在现实世界的项目中如何使用它们？
代理，装饰器，适配器和桥都是“包装”类的变体。但他们的用途不同。
countStudents()，reportAttendance()，assignSubstituteTeacher()等方法。说到详细的实现，我发现Proxy和Decorator，Adapter，Facade之间的区别......在这些模式的通常实现中，有一个由封闭对象包装的目标对象。客户端使用封闭对象而不是目标对象。目标对象实际上在封闭对象的一些方法中起着重要作用。
但是，在Proxy的情况下，封闭对象可以自己播放一些方法，它只是在客户端调用它需要目标对象参与的一些方法时初始化目标对象。这是惰性初始化。在其他模式的情况下，封闭对象实际上基于目标对象。因此，始终将目标对象与构造函数/ setter中的封闭对象一起初始化。
另一方面，代理完全执行目标所做的事情，而其他模式则为目标添加更多功能。
我想在Bill Karwing的回答中添加一些例子（这很棒。）我还添加了一些实现的关键差异，我觉得很遗憾
引用的部分来自[https://stackoverflow.com/a/350471/1984346]（Bill Karwing）的回答
代理，装饰器，适配器和桥都是“包装”类的变体。但他们的用途不同。
- 当您想要延迟实例化对象时，可以使用代理，或者隐藏您正在调用远程服务或控制对象访问的事实。
代理的ProxyClass和ObjectClass应该实现相同的接口，因此它们是可互换的
示例 - 代理昂贵的对象
class ProxyHumanGenome implements GenomeInterface {
private $humanGenome = NULL;
// humanGenome class is not instantiated at construct time
function __construct() {
}
function getGenomeCount() {
if (NULL == $this->humanGenome) {
$this->instantiateGenomeClass();
}
return $this->humanGenome->getGenomeCount();
}
}
class HumanGenome implement GenomeInterface { ... }
- Decorator也被称为“智能代理”。当您想要向对象添加功能时使用此功能，但不能通过扩展该对象的类型来使用。这允许您在运行时执行此操作。
DecoratorClass应该（可以）实现ObjectClass的扩展接口。所以ObjectClass可以被DecoratorClass替换，但反之亦然。
示例 - 添加附加功能
class DecoratorHumanGenome implements CheckGenomeInterface {
// ... same code as previous example
// added functionality
public function isComplete() {
$this->humanGenome->getCount >= 21000
}
}
interface CheckGenomeInterface extends GenomeInterface {
public function isComplete();
}
class HumanGenome implement GenomeInterface { ... }
- 当您具有抽象接口时，将使用适配器，并且您希望将该接口映射到具有类似功能角色但具有不同接口的另一个对象。
实现差异代理，装饰器，适配器
适配器为其主题提供不同的界面。代理提供相同的接口。 Decorator提供增强的界面。
- Bridge与Adapter非常相似，但是当您定义抽象接口和底层实现时，我们将其称为Bridge。即如果您不适应某些遗留代码或第三方代码，那么您就是所有代码的设计者，但您需要能够交换不同的实现。
- Facade是一个更高级别（读取：更简单）的接口，用于一个或多个类的子系统。假设您有一个复杂的概念，需要多个对象来表示。对这组对象进行更改会让人感到困惑，因为您并不总是知道哪个对象具有您需要调用的方法。现在是编写Facade的时候了，它可以为您可以对对象集合执行的所有复杂操作提供高级方法。示例：学校部分的域模型，使用
countStudents()，reportAttendance()，assignSubstituteTeacher()等方法。
本答案中的大部分信息来自https://sourcemaking.com/design_patterns，我建议将其作为设计模式的优秀资源。
我相信代码会给出一个明确的想法（以补充其他答案）。请看下面，（关注类实现和包装的类型）
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace TestConsole
{
class Program
{
static void Main(string[] args)
{
/* Proxy */
Console.WriteLine(Environment.NewLine);
Console.WriteLine("PROXY");
Console.WriteLine(Environment.NewLine);
//instead of creating here create using a factory method, the facory method will return the proxy
IReal realProxy = new RealProxy();
Console.WriteLine("calling do work with the proxy object ");
realProxy.DoWork();
Console.WriteLine(Environment.NewLine);
Console.WriteLine("ADAPTER");
Console.WriteLine(Environment.NewLine);
/*Adapter*/
IInHand objectIHave = new InHand();
Api myApi = new Api();
//myApi.SomeApi(objectIHave); /*I cant do this, use a adapter then */
IActual myAdaptedObject = new ActualAdapterForInHand(objectIHave);
Console.WriteLine("calling api with my adapted obj");
myApi.SomeApi(myAdaptedObject);
Console.WriteLine(Environment.NewLine);
Console.WriteLine("DECORATOR");
Console.WriteLine(Environment.NewLine);
/*Decorator*/
IReady maleReady = new Male();
Console.WriteLine("now male is going to get ready himself");
maleReady.GetReady();
Console.WriteLine(Environment.NewLine);
IReady femaleReady = new Female();
Console.WriteLine("now female is going to get ready her self");
femaleReady.GetReady();
Console.WriteLine(Environment.NewLine);
IReady maleReadyByBeautician = new Beautician(maleReady);
Console.WriteLine("now male is going to get ready by beautician");
maleReadyByBeautician.GetReady();
Console.WriteLine(Environment.NewLine);
IReady femaleReadyByBeautician = new Beautician(femaleReady);
Console.WriteLine("now female is going to get ready by beautician");
femaleReadyByBeautician.GetReady();
Console.WriteLine(Environment.NewLine);
Console.ReadLine();
}
}
/*Proxy*/
public interface IReal
{
void DoWork();
}
public class Real : IReal
{
public void DoWork()
{
Console.WriteLine("real is doing work ");
}
}
public class RealProxy : IReal
{
IReal real = new Real();
public void DoWork()
{
real.DoWork();
}
}
/*Adapter*/
public interface IActual
{
void DoWork();
}
public class Api
{
public void SomeApi(IActual actual)
{
actual.DoWork();
}
}
public interface IInHand
{
void DoWorkDifferently();
}
public class InHand : IInHand
{
public void DoWorkDifferently()
{
Console.WriteLine("doing work slightly different ");
}
}
public class ActualAdapterForInHand : IActual
{
IInHand hand = null;
public ActualAdapterForInHand()
{
hand = new InHand();
}
public ActualAdapterForInHand(IInHand hnd)
{
hand = hnd;
}
public void DoWork()
{
hand.DoWorkDifferently();
}
}
/*Decorator*/
public interface IReady
{
void GetReady();
}
public class Male : IReady
{
public void GetReady()
{
Console.WriteLine("Taking bath.. ");
Console.WriteLine("Dress up....");
}
}
public class Female : IReady
{
public void GetReady()
{
Console.WriteLine("Taking bath.. ");
Console.WriteLine("Dress up....");
Console.WriteLine("Make up....");
}
}
//this is a decorator
public class Beautician : IReady
{
IReady ready = null;
public Beautician(IReady rdy)
{
ready = rdy;
}
public void GetReady()
{
ready.GetReady();
Console.WriteLine("Style hair ");
if (ready is Female)
{
for (int i = 1; i <= 10; i++)
{
Console.WriteLine("doing ready process " + i);
}
}
}
}
}
设计模式不是数学，它是艺术与软件工程的结合。没有什么比这个要求你必须使用代理，桥接等。创建设计模式来解决问题。如果您预计到设计问题，请使用它。根据经验，您将了解具体问题，使用哪种模式。如果你擅长坚实的设计原则，你就可以实现设计模式而不需要知道模式。常见的例子是statergy和工厂模式
因此，更多地关注固体设计原则，清洁编码原则和ttd
As Bill's answer says, their use cases are different。
他们的结构也是如此。
我对这个问题的看法。
所有四种模式都有很多共同点，所有这四种模式有时被非正式地称为包装器或包装器模式。所有使用组合，包装主题并在某个时刻将执行委托给主题，将一个方法调用映射到另一个方法调用。它们使客户无需必须构建不同的对象并复制所有相关数据。如果使用得当，它们可以节省内存和处理器。
通过促进松散耦合，他们可以使稳定的代码更少地暴露于不可避免的变化，并且对于其他开发人
适配器
适配器使主体（适配器）适应不同的接口。这样我们就可以将对象添加到名义上不同类型的集合中。
适配器仅向客户端公开相关方法，可以限制所有其他方法，揭示特定上下文的使用意图，如调整外部库，使其看起来不那么通用，更专注于我们的应用程序需求。适配器提高了代码的可读性和自我描述。
适配器使一个团队免受其他团队的易变代码的攻击;处理离岸团队时的救生员工具;-)
较少提及的目的是防止主题类过多的注释。有了这么多基于注释的框架，这就变得越来越重要了。
适配器有助于克服仅限单一继承的Java限制。它可以将几个适应者组合在一个信封下，给人以多重继承的印象。
代码方面，适配器是“瘦”。除了简单地调用adaptee方法和进行此类调用所必需的偶尔数据转换之外，它不应该向adaptee类添加太多代码。
JDK或基本库中没有很多好的适配器示例。应用程序开发人员创建适配器，以使库适应应用程序特定的接口
装饰
Decorator不仅委托，不仅将一个方法映射到另一个方法，它们做得更多，它们修改了一些主题方法的行为，它可以决定不调用主题方法，委托给不同的对象，一个辅助对象。
装饰器通常将（透明）功能添加到包装对象，如记录，加密，格式化或压缩到主题。这个新功能可能会带来很多新代码。因此，装饰器通常比适配器“更胖”。
装饰器必须是主题界面的子类。它们可以透明地使用而不是它的主题。请参阅BufferedOutputStream，它仍然是OutputStream，可以这样使用。这是Adapters的主要技术差异。
JDK中的整个装饰器系列的教科书示例很容易 - Java IO。像BufferedOutputStream，FilterOutputStream和ObjectOutputStream这样的所有类都是OutputStream的装饰者。它们可以是洋葱层，再一次装饰一个装饰，增加更多功能。
代理
代理不是典型的包装器。在创建代理时，包装对象（代理主题）可能尚不存在。代理通常在内部创建它。它可能是按需创建的繁重对象，也可能是不同JVM或不同网络节点中的远程对象，甚至是非Java对象（本机代码中的组件）。它根本没有必要包装或委托给另一个对象。
最典型的例子是远程代理，重对象初始化器和访问代理。
正面
立面与最小知识的设计原则（德米特定律）密切相关。 Facade与Adapter非常相似。它们都包装，它们都将一个对象映射到另一个对象，但它们的意图不同。 Facade展平了主题的复杂结构，复杂的对象图，简化了对复杂结构的访问。
Facade包裹着一个复杂的结构，为它提供了一个平面界面。这可以防止客户端对象暴露于主题结构中的内部关系，从而促进松耦合。
桥
适配器模式的更复杂的变体，其中不仅实现变化而且抽象。它为代表团增加了一个间接性。额外的授权是桥梁。它甚至可以从适配接口中解耦适配器。它比任何其他包装模式更增加复杂性，因此请小心使用。
构造函数的差异
在查看构造函数时，模式差异也很明显。
现实生活中的例子 - JAXB Marshalling Adapter。此适配器的用途是将简单的平面类映射到外部所需的更复杂的结构，并防止使用过多的注释“污染”主题类。
许多GoF模式存在很多重叠。它们都建立在多态性的力量之上，有时只在意图上有所不同。 （战略与国家）
阅读Head First Design Patterns后，我对模式的理解增加了100倍。
我强烈推荐它！
专家们的所有好答案都已经解释了每种模式的含义。
我将装饰关键点。
装饰：
例如（带链接）：与java.io和InputStream接口相关的OutputStream包类
FileOutputStream fos1 = new FileOutputStream("data1.txt");
ObjectOutputStream out1 = new ObjectOutputStream(fos1);
代理：
例如：java.rmi包装类。
适配器：
例如java.io.InputStreamReader（InputStream返回Reader）
桥：
例如java.util的收集课程。由List实施的ArrayList。
主要说明：
看看有关各种设计模式示例的精彩SE问题/文章
When to Use the Decorator Pattern?
When do you use the Bridge Pattern? How is it different from Adapter pattern?
它们非常相似，它们之间的界线很灰。我建议你阅读c2 wiki中的Proxy Pattern和Decorator Pattern条目。
这里的条目和讨论非常广泛，并且还链接到其他相关文章。顺便说一下，当想知道不同模式之间的细微差别时，c2 wiki非常出色。
为了总结c2条目，我会说装饰器添加/更改行为，但代理更多地与访问控制（延迟实例化，远程访问，安全性等）有关。但就像我说的那样，它们之间的界限是灰色的，我看到代理的引用很容易被视为装饰者，反之亦然。
这是Head First Design Patterns的引用
定义属于书。例子属于我。
装饰器 - 不改变界面，但增加了责任。假设你有一个汽车界面，当你为汽车的不同型号（s，sv，sl）实现这个时，你可能需要为某些型号增加更多的责任。喜欢天窗，安全气囊等。
适配器 - 将一个接口转换为另一个接口。你有一个汽车界面，你希望它像吉普车一样。所以你拿车，修改它，变成吉普车。因为它不是真正的吉普车。但就像吉普车一样。
Facade - 使界面更简单。假设您有汽车，飞机，船舶接口。实际上，你所需要的只是一个将人们从一个地方送到另一个地方的班级。您希望外观决定使用哪种车辆。然后你收集所有这些接口引用，并让它决定/委托以保持简单。
首先：“一个外观不仅简化了界面，它将客户端与组件子系统分离。外观和适配器可以包装多个类，但外观的意图是简化，而适配器是将接口转换为不同的东西。 “
所有这四种模式都涉及用内部对象包装内部对象/类，因此它们在结构上非常相似。我会按目的概述差异：
并通过内部和外部对象之间的接口变化：
我在使用Web服务时经常使用它。代理模式应该可以重命名为更实用的东西，比如'Wrapper Pattern'。我还有一个库，它是MS Excel的代理。它可以很容易地自动化Excel，而不必担心背景细节，比如什么安装版本（如果有）。