设计模式优缺点及应用场景
设计模式的优缺点
设计模式的优缺点设计模式是一种被广泛应用于软件设计领域的解决问题的思维方式，它包括了一系列的解决方案，帮助开发人员快速地解决一些常见的软件设计问题。
然而，在使用设计模式时，我们也需要认清它的优点和缺点。
优点1. 可维护性提高设计模式将软件拆分成多个独立的组件，这些组件之间具有低耦合性和高内聚性，这使得维护变得更加容易。
在软件需求发生变化时，只需要修改一个组件而不影响其他组件，同时也使得代码重用变得更加容易，大大提高了软件的可维护性。
2. 可扩展性提高当软件需求发生变化，我们可以很方便地往软件中加入新的组件，修改现有的组件，使得软件的功能得到扩展。
设计模式将组件之间的关系更加清晰，使得扩展变得更加容易。
3. 代码重用性提高设计模式将模块划分为不同的组件，每个组件都有自己的职责和功能，这使得组件可以在不同的软件中进行复用，避免了代码重复的情况出现，提高了软件的编写效率。
4. 提高代码可读性设计模式的使用有助于提高代码的可读性。
由于每个组件职责单一而明确，所以代码的逻辑结构变得更加清晰，使得代码更加易于维护和理解。
5. 软件质量提高通过设计模式，软件稳定性更高、可靠性更强，避免了出现一些常见的错误，同时，设计模式的使用也使得软件的架构更加合理，功能更加完善，从而提高了软件的质量。
缺点1. 学习和使用门槛较高设计模式是一种高级的软件设计思维方式，学习和使用门槛较高，需要有一定的编程经验和对软件设计的理解。
同时，在实际使用中，需要将其应用到实际场景中，设计合理的组件结构，这也需要一定的技术经验和实践经验。
2. 可能会影响软件性能设计模式在增加软件的灵活性和可扩展性的同时，可能也会增加代码的复杂性，导致软件性能的下降。
因此，在使用设计模式时，需要在可维护性和性能之间做出平衡，根据实际情况选择合适的方案。
3. 可能会导致过度工程化由于设计模式有助于提高软件可维护性、可扩展性和代码可读性，因此在使用过度的情况下，可能会导致代码变得过于复杂和冗长，增加开发人员的工作量，同时也可能会对软件的开发周期和成本造成影响。
单例设计模式优缺点及使用场景
单例设计模式优缺点及使⽤场景单利模式的优缺点和使⽤场景⾸先介绍⼀下单例模式：单例模式（Singleton），也叫单⼦模式，是⼀种常⽤的软件设计模式。
在应⽤这个模式时，单例对象的类必须保证只有⼀个实例存在。
许多时候整个系统只需要拥有⼀个的全局对象，这样有利于我们协调系统整体的⾏为。
⽐如在某个服务器程序中，该服务器的配置信息存放在⼀个⽂件中，这些配置数据由⼀个单例对象统⼀读取，然后服务进程中的其他对象再通过这个单例对象获取这些配置信息。
这种⽅式简化了在复杂环境下的配置管理。
实现单例模式的思路是：⼀个类能返回对象⼀个引⽤(永远是同⼀个)和⼀个获得该实例的⽅法（必须是静态⽅法，通常使⽤getInstance这个名称）；当我们调⽤这个⽅法时，如果类持有的引⽤不为空就返回这个引⽤，如果类保持的引⽤为空就创建该类的实例并将实例的引⽤赋予该类保持的引⽤；同时我们还将该类的构造函数定义为私有⽅法，这样其他处的代码就⽆法通过调⽤该类的构造函数来实例化该类的对象，只有通过该类提供的静态⽅法来得到该类的唯⼀实例。
需要注意的地⽅：单例模式在多线程的应⽤场合下必须⼩⼼使⽤。
如果当唯⼀实例尚未创建时，有两个线程同时调⽤创建⽅法，那么它们同时没有检测到唯⼀实例的存在，从⽽同时各⾃创建了⼀个实例，这样就有两个实例被构造出来，从⽽违反了单例模式中实例唯⼀的原则。
解决这个问题的办法是为指⽰类是否已经实例化的变量提供⼀个互斥锁(虽然这样会降低效率)。
优点：1.在单例模式中，活动的单例只有⼀个实例，对单例类的所有实例化得到的都是相同的⼀个实例。
这样就防⽌其它对象对⾃⼰的实例化，确保所有的对象都访问⼀个实例2.单例模式具有⼀定的伸缩性，类⾃⼰来控制实例化进程，类就在改变实例化进程上有相应的伸缩性。
3.提供了对唯⼀实例的受控访问。
4.由于在系统内存中只存在⼀个对象，因此可以节约系统资源，当需要频繁创建和销毁的对象时单例模式⽆疑可以提⾼系统的性能。
软件设计模式及应用场景分析
软件设计模式及应用场景分析随着计算机技术的不断发展和应用范围的扩大，软件开发变得越来越复杂、庞大，软件设计的可靠性和可维护性也随之变得更加重要。
为了解决这些问题，软件设计模式应运而生。
软件设计模式被定义为一组可用于解决特定问题的重复性方案。
它们旨在提高软件开发的效率和可重用性，并增加代码的可读性和可维护性。
设计模式是编程中的一种有力工具，它们提供了一种有效的方法，用于解决复杂问题和设计灵活的、可扩展的解决方案。
常见的设计模式以下是一些常见的软件设计模式：1. 工厂模式：一种创建对象的方式，它隐藏了对象的创建细节，使得代码更加灵活和可扩展。
2. 单例模式：一种确保一个类只有一个实例并提供全局访问的方式。
3. 观察者模式：一种在对象之间建立一种订阅和发布关系的方式，当一个对象状态发生改变时，其他对象都会被通知并执行相应的操作。
4. 策略模式：一种在 runtime 时选择执行哪种算法的方式。
5. 适配器模式：一种将一个接口转换为另一个接口的方式，从而让原来不兼容的对象能够协同工作。
6. 模板方法模式：一种通过定义算法骨架来提供代码复用的方式，允许子类在不改变算法基本框架的情况下重新定义算法的某些步骤。
7. 装饰者模式：一种在运行时动态扩展一个对象的功能的方式，通过将一个装饰类包装在一个现有对象的外部来实现对该对象的扩展。
8. 迭代器模式：允许客户端遍历容器中的元素，而无需了解容器的内部实现，从而提供更好的代码抽象。
应用场景以下是几个适合使用设计模式的场景：1. 软件系统需要大量的复杂对象。
2. 软件系统需要扩展性高，可维护性好。
3. 软件系统需要在运行时动态改变算法。
4. 软件系统需要隐藏对象的创建细节。
总结软件设计模式是一种帮助开发人员提高软件开发效率和代码可读性的重要工具。
它们不仅提供了一种解决特定问题的方法，还提供了一种通用解决方案，能够帮助开发人员更好地组织和管理代码。
在选择使用设计模式时，需要考虑到软件系统的需求以及其未来的发展方向。
10种常见的软件体系架构模式分析以及它们的用法、优缺点
10种常见的软件体系架构模式分析以及它们的用法、优缺点有没有想过要设计多大的企业规模系统？在主要的软件开发开始之前，我们必须选择一个合适的体系结构，它将为我们提供所需的功能和质量属性。
因此，在将它们应用到我们的设计之前，我们应该了解不同的体系结构。
根据维基百科中的定义：
架构模式是一个通用的、可重用的解决方案，用于在给定上下文中的软件体系结构中经常出现的问题。
架构模式与软件设计模式类似，但具有更广泛的范围。
在本文中，将简要地解释以下10种常见的体系架构模式，以及它们的用法、优缺点。
一. 分层模式
这种模式也称为多层体系架构模式。
它可以用来构造可以分解为子任务组的程序，每个子任务都处于一个特定的抽象级别。
每个层都为下一个提供更高层次服务。
一般信息系统中最常见的是如下所列的4层。
•表示层(也称为UI层)•应用层(也称为服务层)•业务逻辑层(也称为领域层)•数据访问层(也称为持久化层)
使用场景：•一般的桌面应用程序•电子商务Web应用程序
二. 客户端-服务器模式
这种模式由两部分组成：一个服务器和多个客户端。
服务器组件将为多个客户端组件提供服务。
客户端从服务器请求服务，服务器为这些客户端提供相关服务。
此外，服务器持续侦听客户机请求。
使用场景：•电子邮件，文件共享和银行等在线应用程序
三. 主从设备模式
这种模式由两方组成;主设备和从设备。
主设备组件在相同的从设备组件中分配工作，并计算最终结果，这些结果是由从设备返回的结果。
使用场景：•在数据库复制中，主数据库被认为是权威的来源，并且要与之同步•在计算。
三个及以上的设计模型,并比较其各自优缺点
一、表述三个及以上的设计模型，并比较其各自优缺点1、瀑布模型：瀑布模型（Waterfall Model）是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。
包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。
瀑布模型的优点：（1）为项目提供了按阶段划分的检查点（2）当前一阶段完成后，您只需要去关注后续阶段（3）可在迭代模型中应用瀑布模型瀑布模型的缺点：（1）开发过程一般不能逆转，否则代价太大；（2）实际的项目开发很难严格按该模型进行；（3）客户往往很难清楚地给出所有的需求，而该模瀑布模型的使用范围：型却要求如此。
（4）软件的实际情况必须到项目开发的后期客户才能看到，这要求客户有足够的耐心。
2、快速原型模型快速原型模型需要迅速建造一个可以运行的软件原型，以便理解和澄清问题，使开发人员与用户达成共识，最终在确定的客户需求基础上开发客户满意的软件产品。
快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。
优点：（1）可以得到比较良好的需求定义，容易适应需求的变化；（2）有利于开发与培训的同步；（3）开发费用低、开发周期短且对用户更友好。
缺点：（1）客户与开发者对原型理解不同；（2）准确的原型设计比较困难；（3）不利于开发人员的创新。
3、增量模型增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。
设计模式.装饰模式(Decorator)
性或者继承层次过深。
需要对一组基本功能进行排列 组合以产生非常多的功能，而 使用继承关系很难实现这样的 需求。
需要在不修改现有代码的情况 下对程序进行功能扩展。
02
装饰模式的实现方式
继承实现方式
1 2 3
优点
代码简洁，易于理解。
缺点
不够灵活，每增加一个新的装饰功能，都需要创 建一个新的子类，类数量会急剧增加，导致系统 庞大和复杂。
03 需要对一组基本功能进行排列组合以产生非常多 的功能。
对未来研究的展望
深入研究装饰模式的适用场 景和最佳实践，以便更好地 应用该模式解决实际问题。
研究如何将装饰模式与其 他设计模式结合使用，以 产生更好的设计效果。
ABCD
探索如何降低装饰模式的 复杂性，提高代码的可读 性和维护性。
关注新兴技术和编程语言对装 饰模式的影响，以便及时调整 和更新该模式的应用方式。
可能破坏封装性
在使用装饰模式时，需要注意不要破坏对象的封 装性。如果装饰器暴露了对象的内部状态或实现 了不应该暴露的方法，那么可能会导致系统的不 稳定性和安全性问题。
06
总结与展望
对装饰模式的总结
优点 装饰模式可以在不改变对象自身的基础上，动态地给对象添加一些额外的职责。
装饰模式可以在运行时选择性地添加或删除某些功能，提高了系统的灵活性。
统或类的整合和简化。
03
透明性不同
装饰模式对客户端是透明的，客户端可以无感知地使用被装饰的对象，
而外观模式则可能需要对客户端进行一定的定制，以提供简化的接口。
与桥接模式的比较
目标不同
装饰模式的目标是动态地给一个对象添加一些额外的职责， 而桥接模式的目标是将抽象部分与它的实现部分分离，使 它们都可以独立地变化。
设计模式.解释器模式(Interpreter
维护文法规则
随着业务需求的变化，可能需要调整或扩展 文法规则，因此需要对解释器进行相应的维 护和更新。
THANKS
感谢观看
与访问者模式比较
访问者模式可以在不修改已有 类的情况下增加新的操作，而 解释器模式则关注于如何解析 和执行特定的语言或脚本。两 者都涉及对对象结构的操作， 但关注点不同。
解释器模式在软件开发中应
06
用实践
需求分析阶段应用
01
确定语言文法
在需求分析阶段，通过对业务领域进行深入分析， 可以明确需要解释的语言的文法规则。
的代码，符合开闭原则。
灵活性高
解释器模式可以动态地改变解释逻辑， 从而灵活地处理各种复杂的语言或脚
本。
缺点与不足
性能问题
01
解释器模式通常比编译执行的语言慢，因为解释器需要动态解
析和执行代码。
错误处理困难
02
由于解释器模式通常涉及动态执行代码，因此错误处理和调试
可能更加困难。
语法复杂度高
03
对于复杂的语法结构，解释器模式可能需要实现复杂的解析逻
03
设计模式使代码编制真正工程化，是软件工程的基石脉络。
解释器模式定义
解释器模式（Interpreter Pattern）是一种行为 设计模式，它提供了一种解释语言的语法或表达 式的方式，并定义了一个解释器接口，用于解释 这些语法或表达式。
解释器模式通常用于实现一个简单的语言解释器 或编译器，或者用于解析和执行复杂的数学表达 式等。
解释器模式使得规则引擎具有高度的灵活性和可扩展性。业务规则可以独立于应用程序进行修改和扩展， 而无需修改应用程序代码。
设计模式理解与应用
设计模式理解与应用设计模式是指在软件开发中，经常遇到的一些具有普遍重用价值的问题的解决方案，是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。
设计模式是一种高级软件解决方案，它将软件开发中的各种可重用的问题进行了通用化的抽象和描述，从而形成了一种通用的模式，可以被开发人员按照一定的规则和原则应用于具体的软件设计中。
第一章：理解设计模式设计模式的概念最早由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四个人在 1995 年提出，他们在《设计模式：可复用面向对象软件的基础》一书中介绍了 23 种常用的设计模式。
设计模式是一种经过长期验证，具有一定普遍性的解决方案，它并不把所有的问题都囊括进去，因此我们在使用时要根据实际情况去选择适合的模式。
设计模式通常分为 3 大类：创建型模式、结构型模式和行为型模式。
创建型模式主要解决对象的创建问题，包括单例模式、工厂模式、抽象工厂模式、建造者模式、原型模式。
结构型模式主要解决组合对象和对象之间的关系问题，包括适配器模式、桥接模式、装饰器模式、组合模式、外观模式、享元模式、代理模式。
行为型模式主要针对对象之间的通信问题，包括责任链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式。
第二章：应用设计模式设计模式的使用，可以大大提高软件的开发效率和质量，但在使用之前，必须先对设计模式进行深入的学习和理解。
在实际应用中，我们要充分评估自己的开发需求，并根据实际情况，在设计阶段中使用其中一些设计模式。
例如，当我们需要使用一个日志库来记录系统运行过程中产生的各种日志信息时，可以采用单例模式来保证系统中只有一个日志实例，这样可以避免资源的浪费，提高系统效率。
再如，当我们需要使用一个网络连接库，在不同的平台中都能够正确地实现网络连接时，可以使用抽象工厂模式，通过工厂方法来创建各种不同类型的网络连接，从而在不同平台中实现连接的正确性和可靠性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
看完发现有不太对的地方告诉我下各设计模式优缺点总结1桥接模式优点：1将实现予以解耦，让它和界面之间不再永久绑定2抽象和实现可以独立扩展，不会影响到对方3对于“具体的抽象类”所做的改变，不会影响到客户。
缺点：1.增加了复杂度用途：1.适合使用在需要跨越多个平台的图形和窗口上2.当需要用不同的方式改变接口和实现时，你会发现桥接模式很好用。
具体实例：跨平台的软件，不同电视机和不同的遥控器。
2生成器模式（建造者模式）优点：1.将一个复杂对象的创建过程封装起来2.允许对象通过多个步骤来创建，并且可以改变创建过程3.向客户隐藏内部的表现4.产品的实现可以被替换，因为客户只看到一个抽象的接口缺点：1.与工厂模式相比，采用生成器模式创建对象更复杂，其客户，需要更多的知识领域。
用处：用来创建组合结构。
典型例子：想不起典型例子还是扯那个画小人，构建小人分画头，画身体，画双手，黄双脚等不同构建部分，全部放在一起构建。
3职责链模式优点：1.将请求的发送者和接收者解耦2.可以简化你的对象，因为它不需要知道链的结构3.通过改变链内的成员或调动他们的次序，允许你动态地新增或删除责任缺点：1.并不保证请求一定会被执行，如果没有任何对象处理它的话，它可能会落到链尾端之外2.可能不容观察运行时的特征，有碍于除错。
用途：经常被使用在窗口系统中，处理鼠标和键盘之类的事件。
当算法牵涉到一种链型运算，而且不希望处理过程中有过多的循环和条件选择语句，并且希望比较容易的扩充文法，可以采用职责链模式。
1）有多个对象处理请求，到底怎么处理在运行时确定。
2）希望在不明确指定接收者的情况下，向多个对象中的一个提交请求。
3）可处理一个请求的对象集合应该被动态指定。
典型例子：一个请求发送给前台，前台表示我无权管理，将请求传递给财务部门，财务部门再……4蝇量模式（享元）优点：1.减少运行时对象实例的个数，节省内存2.将许多“虚拟”对象的状态集中管理缺点：一旦你实现了它，单个的逻辑实现将无法拥有独立而不同的行为用途：当一个类有许多的实例，而这些实例能被同一方法控制的时候，我们就可以使用蝇量模式。
（这话什么意思啊，HF书上原话，是这话有问题还是我理解能力有问题?!）具体场景：五子棋中的黑白子，改变坐标状态(x,y)，但用同一个实体。
5解释器模式（这个模式我真没仔细看）优点：1．将每一个语法规则表示成一个类，方便事先语言。
2．因为语法由许多类表示，所以你可以轻易地改变或扩展此语言3．通过在类结构中加入新的方法，可以在解释的同时增加新的行为，例如打印格式的梅花或者进行复制的程序验证。
缺点：当语法规则数目太大时，这个模式可能会变得非常繁琐。
用途：1．当你需要实现一个简答的语言时，使用解释器2．当你有一个简单的语法，切简单比效率更重要时，使用解释器3．可以处理脚本语言和编程语言典型例子：正则表达式6中介者模式优点：1.通过将对象彼此解耦，可以增加对象的复用性。
2.通过将控制逻辑集中，可以简化系统维护3.可以让对象之间传递的消息变得简单而且大幅减少缺点：1.如果设计不当，中介者对象本身会变得过于复杂用途：常常被用来协调相关的GUI组件(HF设计模式上的原话，这书附录A部分真的有点敷衍)经典例子：我租房，但没有户主信息，我和户主不能直接交替。
没关系，中介者类有我和户主的信息，private我，private户主。
而我和户主都认识中介者。
我将信息传递给中介者，在我中调用中介者.获取信息（）方法，中介者获取信息后，再由中介者传递给户主。
7备忘录模式优点：1.将被存储的状态放在外面，不要和关键对象混在一起，可以帮助维护内聚2.保持关键对象的数据封装3.提供了容易实现的恢复能力缺点：1.储存和恢复状态的过程可能相当耗时用途备忘录模式用于存储状态，在java中可以使用序列化。
经典例子：游戏中途保存游戏，这时候可以调用保存当前状态方法，再读取的时候调用读取。
Java序列化机制在这方面非常的方便。
8原型模式优点：1.向客户隐藏制造新实例的复杂性2.提供让客户能够产生未知类型对象的选项3.在某些环境下，复制对象比新建对象更有效缺点：复制对象有时相当复杂用途：在一个复制的类层次中，当系统必须从其中的许多类型创建新对象时，可以考虑原型模式。
经典例子：随便拿一个类，给这个类写一个克隆方法，复制当前对象。
或者直接用反序列化。
9访问者模式优点：1.允许你对组合结构加入新的操作，无需改变结构本身2.想要加入新的操作相对容易3.访问者所进行的操作，其代码是集中在一起的缺点：1.会打破组合类的封装2.因为游走的功能牵涉其中，随意对组合结构的改变就更加困难。
用途：有比较稳定的数据结构，又有易于变化的算法的话，使用访问者模式就是比较合适的，因为访问者模式使得算法操作的增加变得容易。
经典场景：特么访问者模式和翻译器模式，一个看不懂，一个怎么也不想看，到时候要是让我说这两个模式，我就自认倒霉。
10简单工厂模式优点：工厂类是整个模式的关键.包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象.通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。
而不必管这些对象究竟如何创建及如何组织的．明确了各自的职责和权利，有利于整个软件体系结构的优化。
缺点：由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。
当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求．这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利；用途：工厂类负责创建的对象比较少；客户只知道传入工厂类的参数，对于如何创建对象（逻辑）不关心；由于简单工厂很容易违反高内聚责任分配原则，因此一般只在很简单的情况下应用。
经典例子：没啥好说的，这不是一个真正的设计模式11策略模式优点：1.提供了一种替代继承的方法，而且保持了继承的优点，比继承更独立(算法独立，可以任意扩展)2.避免程序使用多重条件转移语句，使系统更灵活，并易于扩展3.遵守大部分常用设计原则，高内聚，低耦合缺点：1.每个具体策略类都会产生一个新类，所以会增加系统需要维护的类的数量。
可以使用工厂方法来解决。
用途：各个不同地区不同的纳税方法，HF中不同鸭子的方法。
有多种鸭子，每个鸭子都有自己的行为，fly，quaak之类的。
行为有行为类，继承同一接口实现不同操作，以此实现算法互换。
12装饰模式优点：1.装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰模式可以提供比继承更多的灵活性。
2.通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。
3.有着比继承更加灵活的特性缺点：由于使用装饰模式，可以比使用继承关系需要较少数目的类。
使用较少的类，当然使设计比较易于进行。
但是，在另一方面，使用装饰模式会产生比使用继承关系更多的对象。
更多的对象会使得查错变得困难，特别是这些对象看上去都很相像。
用途：当需要给一个类添加新的行为的时候，但基于开闭原则，就使用装饰模式。
经典例子：我穿衣服使用draw（）方法，在我穿好衣服后，我还打算再寄领带，而寄领带就是装饰类，我们可以把装饰类和对象（穿衣服类）继承于同一个接口，在装饰类的draw（）方法中调用super.draw（），然后再在这个方法里加上自己的特征。
13代理模式优点：向客户端隐藏了访问某个对象的细节及复杂性；可以动态地调用一个对象中的方法，且无需实现固定的接口。
缺点：（个人见解切勿当真）总觉得代理者不够可靠，不能得到有效的保证，要是对象代理者在维护的时候，或者其他的做出了变动，对被代理的人来说可能带来损失。
使用场景：1.远程代理，可以隐藏一个对象存在于不同地址空间的事实2.虚拟代理，比如html页面刷新的图片，图片一张嘴下载后才能看就是通过虚拟代理来替代了真实的图片，此时代理存储了真实图片的路径和尺寸3.安全代理，用来控制真实对象的访问权限。
一般用于对象应该有不同的访问权限的时候4.智能指引，当调用真实的对象时，代理处理另外一些事。
经典例子：我玩wow，但又没有时间精力投入到里面，于是我请了个人来代练，代练的人和我都继承于玩家类。
而代练者是认识我的，当代练的人开始刷副本的时候，调用代练者.刷副本（）方法,此时他在这个方法中实际调用的是我.刷副本（）。
14工厂方法模式优点：1.良好的封装性，代码结构清晰。
一个对象创建是有条件约束的，如一个调用者需要一个具体的产品对象，只要知道这个产品的类名（或约束字符串）就可以了，不用知道创建对象的艰辛过程，减少模块间的耦合。
2.工厂方法模式的扩展性非常优秀。
在增加产品类的情况下，只要适当地修改具体的工厂类或扩展一个工厂类，就可以完成“拥抱变化”。
例如在我们的例子中，需要增加一个棕色人种，则只需要增加一个BrownHuman类，工厂类不用任何修改就可完成系统扩展。
3.屏蔽产品类。
这一特点非常重要，产品类的实现如何变化，调用者都不需要关心，它只需要关心产品的接口，只要接口保持不表，系统中的上层模块就不要发生变化，因为产品类的实例化工作是由工厂类负责，一个产品对象具体由哪一个产品生成是由工厂类决定的。
在数据库开发中，大家应该能够深刻体会到工厂方法模式的好处：如果使用JDBC连接数据库，数据库从MySql切换到Oracle，需要改动地方就是切换一下驱动名称（前提条件是SQL语句是标准语句），其他的都不需要修改，这是工厂方法模式灵活性的一个直接案例。
4.工厂方法模式是典型的解耦框架。
高层模块值需要知道产品的抽象类，其他的实现类都不用关心，符合迪米特原则，我不需要的就不要去交流；也符合依赖倒转原则，只依赖产品类的抽象；当然也符合里氏替换原则，使用产品子类替换产品父类，没问题！缺点：待补充用途：第一种情况是对于某个产品，调用者清楚地知道应该使用哪个具体工厂服务，实例化该具体工厂，生产出具体的产品来。
JavaCollection中的iterator()方法即属于这种情况。
第二种情况，只是需要一种产品，而不想知道也不需要知道究竟是哪个工厂为生产的，即最终选用哪个具体工厂的决定权在生产者一方，它们根据当前系统的情况来实例化一个具体的工厂返回给使用者，而这个决策过程这对于使用者来说是透明的。
典型例子：车子继承vehicle（车）类，有小汽车卡，公交车bus等，车子工厂实现工厂接口，工厂接口有抽象方法vehicleproducevehicle（Stringtype）方法，车子工厂中实现工厂方法vehicleproducevehicle （StringType），方法中根据需要new新的车子。