23种设计模式 UML 类图及对应示例代码(一)
27种经典设计模式
27种经典设计模式
学习⽬标：
我们都知道设计模式是⼀种⾮常重要的知识，那么我们为何要学习设计模式，怎样才算是真正掌握了设计模式，学习设计模式都应该掌握哪些问题呢？下⾯我们将列举出设计模式相关的若⼲问题，如果你能够正确回答出下⾯的所有问题，那么你对于设计模式的掌握就算是过关了。
你能正确回答出下⾯所列举的所有和设计模式有关的问题吗？
1. 什么是设计模式？他是如何帮助你设计⾯向对象的软件系统的？
2. 根据设计模式的性质分类，27中经典设计模式可以分成哪三类？
3. 设计模式之间有没有关联，有什么样的关联？哪些数据模式可以组合使⽤？
4. 许多⼤型软件系统中实际上同时使⽤了很多种设计模式，如MVC，你知道MVC中都使⽤了哪些设计模式吗？
5. 如果给定你⼀些场景，你能找出适合于此应⽤场景的设计模式吗？（也即，你能不能将相应的设计模式实际运⽤到⾃⼰的项⽬中）
6.
我还不能回答出上述所有问题，我想开始学习：
如果你还不能流利的回答出上述所有问题，那么接下来你要做的就是：开始学习设计模式相关的知识，或者继续更新⾃⼰的现有知识库。
下⾯我会向你推荐若⼲好⽤的资料，希望他们可以帮助你快速掌握设计模式相关的知识：
参考资料1，
这是⼀个在线学习⽹站，⾥⾯详细列举了27中经典设计模式，针对每⼀种设计模式给出了详细解释，并且给出了应⽤实例（包括UML类图和实现代码），可以帮助读者从零开始学习某种设计模式。
另外，该教程也可以作为有经验的读者的“速查⼿册”来使
⽤。
参考资料2，。
UML各种图例齐全—用例图、类图、状态图、包图、协作图、顺序图详细说明画法和功能
UML各种图例面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language™），这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association（或简称通讯communication）角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线.一个用例图是角色，用例，和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.决定特征（需求）.当系统已经分析好并且设计成型时，新的用例产生新的需求∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式：Cash，Check，或者Credit.订单包括OrderDetails（line item），每个这种类都连着Item.UML类的符号是一个被划分成三块的方框：类名，属性，和操作.抽象类的名字，像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association－表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中，关联用两个类之间的连线表示.dependencies关系.如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时（特别是递归关系时）很有用.这个类图示一个大学的Department可以包括其他很多的Departments.这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚，类或实例名可以在对象图中被省略.每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴，时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色.在序列图中，对象的角色放在上面而消息则是连接线.对象角色矩形上标有类或对象名（或者都有）.类名前面有个冒号（：）.协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号，再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN，另一个则在上Getting PIN.初始状态（黑色圆圈）是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用（/动作）表示.当进入Validating状态时，对象并不等外部事件触发转移.取而代之，它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说，我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.。
UML科普文，一篇文章掌握14种UML图
UML科普⽂，⼀篇⽂章掌握14种UML图前⾔上⼀篇⽂章写了⼀篇建造者模式，其中有⼏个UML类图，有的读者反馈看不懂了，我们今天就来解决⼀哈。
什么是UML？UML是Unified Model Language的缩写，中⽂是统⼀建模语⾔，是由⼀整套图表组成的标准化建模语⾔。
为什么要⽤UML？通过使⽤UML使得在软件开发之前，对整个软件设计有更好的可读性，可理解性，从⽽降低开发风险。
同时，也能⽅便各个开发⼈员之间的交流。
UML提供了极富表达能⼒的建模语⾔，可以让软件开发过程中的不同⼈员分别得到⾃⼰感兴趣的信息。
Page-Jones 在《Fundamental Object-Oriented Design in UML》⼀书中总结了UML的主要⽬的，如下：1. 为⽤户提供现成的、有表现⼒的可视化建模语⾔，以便他们开发和交换有意义的模型。
2. 为核⼼概念提供可扩展性 (Extensibility) 和特殊化 (Specialization) 机制。
3. 独⽴于特定的编程语⾔和开发过程。
4. 为了解建模语⾔提供⼀个正式的基础。
5. ⿎励⾯向对象⼯具市场的发展。
6. ⽀持更⾼层次的开发概念，如协作，框架，模式和组件。
7. 整合最佳的⼯作⽅法 (Best Practices)。
UML图有哪些？UML图分为结构图和⾏为图。
结构图分为类图、轮廓图、组件图、组合结构图、对象图、部署图、包图。
⾏为图⼜分活动图、⽤例图、状态机图和交互图。
交互图⼜分为序列图、时序图、通讯图、交互概览图。
UML图概览什么是类图？【概念】类图是⼀切⾯向对象⽅法的核⼼建模⼯具。
类图描述了系统中对象的类型以及它们之间存在的各种静态关系。
【⽬的】⽤来表⽰类、接⼝以及它们之间的静态结构和关系。
在类图中，常见的有以下⼏种关系。
泛化（Generalization）【泛化关系】是⼀种继承关系，表⽰⼦类继承⽗类的所有特征和⾏为。
【箭头指向】带三⾓箭头的实线，箭头指向⽗类。
UML各种图例齐全—用例图、类图、状态图、包图、协作图、顺序图详细说明书画法和功能
UML各种图例面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language ™），这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成标准文档为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association（或简称通讯communication）标准文档角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线.一个用例图是角色，用例，和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.决定特征（需求）.当系统已经分析好并且设计成型时，新的用例产生新的需求标准文档∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式：Cash，Check，或者Credit.订单包括OrderDetails（line item），每个这种类都连着Item.标准文档UML类的符号是一个被划分成三块的方框：类名，属性，和操作.抽象类的名字，像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association－表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中，关联用两个类之间的连线表示.标准文档标准文档为了简单地表示出复杂的类图，可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型.dependencies关系.如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时（特别是递归关系时）很有用.这个类图示一个大学的Department可以包括其他很多的Departments.标准文档这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚，类或实例名可以在对象图中被省略.标准文档每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴，时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.标准文档协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色.在序列图中，对象的角色放在上面而消息则是连接线.标准文档对象角色矩形上标有类或对象名（或者都有）.类名前面有个冒号（：）.协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.标准文档我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号，再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及 Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.标准文档状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN，另一个则在上Getting PIN.初始状态（黑色圆圈）是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用（/动作）表示.当进入Validating状态时，对象并不等外部事件触发转移.取而代之，它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说，我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和 Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.标准文档标准文档标准文档。
UML中数据流图，用例图，类图，对象图，角色图，活动图，序列图详细讲述保存供参考
UML中数据流图，⽤例图，类图，对象图，⾓⾊图，活动图，序列图详细讲述保存供参考这个⽂章，是我在急需的情况下在园⼦⾥搜索到的，原创作者是：DO-websoftware,为了⾃⼰看⽅便，所以复制到我的空间，希望原创者不要介意哦~~~~很详细的介绍，对我的帮助很⼤，谢谢哦。
类图，对象图，⾓⾊图：⼀、UML中基本的图范畴：在 UML 2 中有⼆种基本的图范畴：结构图和⾏为图。
每个 UML 图都属于这⼆个图范畴。
结构图的⽬的是显⽰建模系统的静态结构。
它们包括类，组件和（或）对象图。
另⼀⽅⾯，⾏为图显⽰系统中的对象的动态⾏为，包括如对象的⽅法，协作和活动之类的内容。
⾏为图的实例是活动图，⽤例图和序列图。
⼆、UML中的类图：1.类图的表⽰：类的 UML 表⽰是⼀个长⽅形，垂直地分为三个区，如图 1 所⽰。
顶部区域显⽰类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
在⼀个类图上画⼀个类元素时，你必须要有顶端的区域，下⾯的⼆个区域是可选择的（当图描述仅仅⽤于显⽰分类器间关系的⾼层细节时，下⾯的两个区域是不必要的）。
描述：顶部区域显⽰类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
当在⼀个类图上画⼀个类元素时，你必须要有顶端的区域，下⾯的⼆个区域是可选择的（当图描述仅仅⽤于显⽰分类器间关系的⾼层细节时，下⾯的两个区域是不必要的）。
·类名：如果是抽象类，则采⽤斜体·类属性列表：name : attribute type 如 flightNumber : Integer，这是最常见的表达形式name : attribute type = default value 如 balance : Dollars = 0，这是带有默认值的表达形式·类⽅法列表：name(parameter list) : type of value returned注意：在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的（例如，分钟，美元，等等）。
uml各种图例及说明
uml各种图例及说明(摘录)1、用例图描述角色以及角色与用例之间的连接关系。
说明的是谁要使用系统，以及他们使用该系统可以做些什么。
一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。
2、类图类图是描述系统中的类，以及各个类之间的关系的静态视图。
能够让我们在正确编写代码以前对系统有一个全面的认识。
类图是一种模型类型，确切的说，是一种静态模型类型。
3、对象图与类图极为相似，它是类图的实例，对象图显示类的多个对象实例，而不是实际的类。
它描述的不是类之间的关系，而是对象之间的关系。
4、活动图描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。
能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。
5、状态图描述类的对象所有可能的状态，以及事件发生时状态的转移条件。
可以捕获对象、子系统和系统的生命周期。
他们可以告知一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。
一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；该图可以确定类的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对象的状态。
状态图是对类图的补充。
6、序列图（顺序图）序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。
顺序图可以用来展示对象之间是如何进行交互的。
顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。
7、协作图和序列图相似，显示对象间的动态合作关系。
可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。
如果强调时间和顺序，则使用序列图；如果强调上下级关系，则选择协作图；这两种图合称为交互图。
8、构件图（组件图）描述代码构件的物理结构以及各种构建之间的依赖关系。
03.设计模式.UML类图
UML（Unified Modeling Language，统一建模语言）。
武汉科技大学
UML简介
UML的诞生
1997年11月，在Ivar Jacoboson、Grady Booch以及James Rumbaugh的共同努力下，UML1.1版本提交给OMG （Object Management Group, 对象管理组织）并获得通 过，UML1.1成为业界标准的建模语言。
Ivar Jacobson博士曾任瑞典爱立信公司的首席软 件体系架构师，负责迄今为止商业上最为成功 的AXE交换机的研发。
Байду номын сангаас
Jacobson《面向对象软件工程》和《UML 语言 用户指南》等著作，已经成为殿堂级的软件经 典著作。
武汉科技大学
UML简介
UML的诞生
从1994年起，Grady Booch和James Rumbaugh在Rational 软件公司开始了UML的创建工作。 1995年，OOSE方法和Objectory方法的创建者Ivar Jacobson也加入其中。 UML三位创始人正式联手，共同为创建一种标准的建 模语言而一起工作，他们将开发出来的产品名称定为
UML简介
武汉科技大学
UML简介
UML“三剑客”
UML是面向对象领域的三位著名的方法学家 Grady Booch，James Rumbaugh(詹姆斯-朗博) 和Ivar Jacobson (伊万· 雅各布森)共同提出的。
Grady Booch
James Rumbaugh
都拥有有影响力的发言权。截至到2010-12-30，OMG拥
有379个会员组织。
武汉科技大学
13种uml简介、工具及示例
13种uml简介、工具及示例UML（Unified Modeling Language）是一种用于软件开发的标准化建模语言，它使用图形表示法来描述软件系统的不同方面。
在软件开发过程中，使用UML可以帮助开发人员更清晰地理解系统的结构和行为，从而更好地进行设计和实现。
UML提供了包括结构模型、行为模型和交互模型在内的多种建模方式，其中每种模型都有各自的符号和语法规则。
通过使用这些模型，开发人员可以将系统分解成不同的部分，然后逐步细化这些部分的设计，以便更好地组织和管理项目。
在UML中，最常用的建模元素包括用例图、类图、时序图、活动图、状态图等。
每种图表都有其特定的用途和表达能力，开发人员可以根据实际需要选择合适的图表进行建模。
除了建模元素外，UML还定义了一系列的建模工具，这些工具可以帮助开发人员更高效地进行建模和分析。
其中一些常用的建模工具包括Enterprise Architect、Rational Rose、StarUML等。
下面将对13种UML简介、工具及示例进行详细介绍：1. 用例图（Use Case Diagram）用例图是UML中描述系统功能和用户交互的基本图表之一。
它用椭圆表示用例，用直线连接用例和参与者，展示了系统外部用户和系统之间的交互。
用例图可以帮助开发人员更清晰地理解系统的功能需求，从而指导系统的设计和实现。
示例：一个简单的在线购物系统的用例图包括用例“浏览商品”、“添加商品到购物车”、“提交订单”等，以及参与者“顾客”和“管理员”。
2. 类图（Class Diagram）类图是UML中描述系统结构和静态关系的基本图表之一。
它用矩形表示类，用线连接类之间的关系，包括关联关系、聚合关系、继承关系等。
类图可以帮助开发人员更清晰地理解系统的对象结构和类之间的关系，从而支持系统的设计和重构。
示例：一个简单的学生信息管理系统的类图包括类“学生”、“课程”、“教师”等，以及它们之间的关系如“选修”、“授课”等。
2.设计模式常用的UML图分析（用例图、类图与时序图）
2.设计模式常⽤的UML图分析（⽤例图、类图与时序图）1-⽤例图概述1. 展现了⼀组⽤例、参与者以及他们之间的关系。
2. ⽤例图从⽤户⾓度描述系统的静态使⽤情况，⽤于建⽴需求模型。
⽤例特征保证⽤例能够正确捕捉功能性需求，判断⽤例是否准确的依据。
1. ⽤例是动宾短语2. ⽤例是相互独⽴的3. ⽤例是由⽤户参与者启动的4. ⽤例要有可观测的执⾏结果5. ⼀个⽤例是⼀个单元参与者 ActorUML中，参与者使⽤⼀个⼩⼈表⽰:1. 参与者为系统外部与系统直接交互的⼈或事务，于系统外部与系统发⽣交互作⽤2. 参与者是⾓⾊⽽不是具体的⼈3. 代表参与者在与系统打交道时所扮演的⾓⾊4. 系统实际运作中，⼀个实际⽤户可能对应系统的多个参与者。
不同⾓⾊也可以只对应⼀个参与者，从⽽代表同⼀参与者的不通实例⽤例 Use Case系统外部可见的⼀个系统功能单元。
系统的功能由系统单元所提供，并通过⼀系列系统单元与⼀个或多个参与者之间交换的消息所表达。
系统单元⽤椭圆表⽰，椭圆中的⽂字简述系统功能:关系 Relationship常见关系类型有关联、泛化、包含和扩展关联 Association表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。
箭头指向：指向消息接收⽅：⼦系统 SubSystem⽤来展⽰系统的⼀部分功能(紧密联系)泛化 Inheritance继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。
⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。
⽗⽤例通常是抽象。
箭头指向：指向⽗⽤例2-类图描述系统中的类，以及各个类之间的关系的静态试图。
表⽰类、接⼝以及它们之间的协作关系，⽤于程序设计阶段。
注意:1. 抽象类或抽象⽅法⽤斜体表⽰2. 如果是接⼝，则在类名上⽅加 <<Interface>>3. 字段和⽅法返回值的数据类型⾮必需4. 静态类或静态⽅法加下划线类图实例:类图中的事务及解释如图，类图从上到下分为三部分,分别为类名、属性和操作1. 属性:如果有属性，则每⼀个属性都必须有⼀个名字，另外还可以有其它的描述信息，如可见性、数据类型、缺省值等2. 操作:如果有操作，则每⼀个操作也都有⼀个名字，其它可选的信息包括可见性、参数的名字、参数类型、参数缺省值和操作的返回值的类型等类图中的六种关系1.实现关系 implements (类实现接⼝)⽤空⼼三⾓虚线表⽰2.泛化关系 extends (表⽰⼀般与特殊的关系) is-a⽤空⼼三⾓实线表⽰3.组合关系 (整体与部分的关系) contains-a实⼼菱形实现表⽰eg.有头类、⾝体类与⼈类类三个类，则⼈类类中应包含头类及⾝体类这两个属性，则⼈类类与头类和⾝体的关系即为组合关系。
7UML 设计模式(1)--Facade,Adapter模式
Gang-of-Four 书中介绍了23种基本的设计 模式（GOF23种设计模式）
UML和设计模式
3
7.1 设计模式概述
什么是设计模式？ 广义上讲，是对被用来在特定场景下解决一般设计 问题的类和相互通信的对象的描述； 狭义的讲，是对特定问题的描述或解决方案。 设计模式的基本要素： 名称、问题、解决方案、模式效果。
UML和设计模式
17
适配器模式中的角色
目标(Target)：即所期待得到的接口（不可是类） 被适配者(Adaptee)：现有的接口，需要适配，否 则无法使用。 适配者(Adapter)：将源接口转换为目标接口；是
具体的类，是本模式的核心。
UML和设计模式
18
7.4.2 对象适配器模式
UML和设计模式 24
// 客户程序中的使用
Target t= new Adapter(); t.Request();
UML和设计模式
25
Adapter模式与Facade模式
Facade模式 是否利用现有的类？ 是否必须按某个接口来设计？ 对象需要多态行为吗？ 设计的接口是更简单的接口吗？ 是 否 否 是 Adapter模式 是 是 可能 否
UML和设计模式
4
7.2 设计模式的分类
按照模式的目的划分：
创建型设计模式：描述如何创建对象，包括：抽象工 厂、建造、原型、单例等模式。 结构型设计模式：描述类和对象间怎样组织，如适配 器、桥接、组合、装饰、外观、享元、代理等模式。 行为型设计模式：描述算法及对象间的任务分配等， 如职责链、命令、迭代器、中介者、备忘录、观察者、 状态、策略、访问者等模式。
UML和设计模式 9
7.3.2 外观模式的例子
23种(只有常用的十种)应用场景举例(详细)
目录1【装饰模式应用场景举例】 ......................................................................................................... 1 2【策略模式应用场景举例】 ......................................................................................................... 5 3【代理模式应用场景举例】 ......................................................................................................... 8 4【外观模式应用场景举例】 ....................................................................................................... 12 5【抽象工厂模式应用场景举例】 ............................................................................................... 14 6【观察者模式应用场景举例】 ................................................................................................... 22 7【建造者模式应用场景举例】 ................................................................................................... 27 8【原型模式应用场景举例】 ....................................................................................................... 32 9【工厂方法模式应用场景举例】 ............................................................................................... 35 10【模板方法模式应用场景举例】 ............................................................................................. 401【装饰模式应用场景举例】 【 】比如在玩“极品飞车”这款游戏，游戏中有对汽车进行喷涂鸦的功能，而且 这个喷涂鸦是可以覆盖的，并且覆盖的顺序也影响到最后车身的显示效果，假设 现在喷涂鸦具有 2 种样式： （1） 红色火焰 （2） 紫色霞光如果使用“继承父类” 设计这样的功能，那么类图就像如下的这样：从图中可以看到使用继承来实现这种功能，并且是 2 种涂鸦样式，就需要创 建 4 个子类，如果喷涂鸦有 3 种，4 种呢？这种情况就是典型中学课程学习过的 “排列与组合”，那简直就是“Head First 设计模式”书中讲的“类爆炸”。
二十三种设计模式
23种设计模式汇集如果你还不了解设计模式是什么的话？那就先看设计模式引言!学习GoF设计模式的重要性建筑和软件中模式之异同A. 创建模式设计模式之Singleton(单态/单件) 阎宏博士讲解：单例（Singleton）模式保证一个类只有一个实例,并提供一个访问它的全局访问点设计模式之Factory(工厂方法和抽象工厂)使用工厂模式就象使用new一样频繁.设计模式之Builder汽车由车轮方向盘发动机很多部件组成，同时，将这些部件组装成汽车也是一件复杂的工作，Builder模式就是将这两种情况分开进行。
设计模式之Proto type(原型)用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
B. 结构模式设计模式之Adapter(适配器)使用类再生的两个方式:组合(new)和继承(extends),这个已经在thinking in java中提到过.设计模式之Proxy(代理)以Jive为例,剖析代理模式在用户级别授权机制上的应用设计模式之Facade(门面？)可扩展的使用JDBC针对不同的数据库编程,Facade提供了一种灵活的实现.设计模式之Composite(组合)就是将类用树形结构组合成一个单位.你向别人介绍你是某单位，你是单位中的一个元素，别人和你做买卖，相当于和单位做买卖。
文章中还对Jive再进行了剖析。
设计模式之Decorator(装饰器)Decorator是个油漆工,给你的东东的外表刷上美丽的颜色.设计模式之Bridge(桥连)将牛郎织女分开(本应在一起,分开他们,形成两个接口),在他们之间搭建一个桥(动态的结合)设计模式之Flyweight(共享元)提供Java运行性能,降低小而大量重复的类的开销.C. 行为模式设计模式之Command(命令)什么是将行为封装,Command是最好的说明.设计模式之Observer(观察者)介绍如何使用Java API提供的现成Observer设计模式之Iterator(迭代器)这个模式已经被整合入Java的Collection.在大多数场合下无需自己制造一个Iterator,只要将对象装入Collection中，直接使用Iterator进行对象遍历。
UML类图详解及类图设计
UML类图详解及类图设计UML中定义了⽤例图、类图、时序图、协作图等九种。
设计模式中经常会⽤到的是类图。
类是⾯向对象系统组织结构的核⼼，类可以说是对⼀组具有相同属性、操作、关系和语义的对象的抽象。
在UML中，类使⽤带有分隔线的矩形表⽰，它包含名称部分（Name）、属性部分（Attribute）和操作部分（Operation）。
其中属性的表现形式是[可见性] 属性名:类型 [=默认值]。
操作的表现形式是：[可见性] 名称（参数列表）[：返回类型]。
详细见下图。
1.类图基础属性+表⽰public-表⽰private#表⽰protected~表⽰default,也就是包权限_下划线表⽰static斜体表⽰抽象2.类之间关系在UML类图中，常见的有以下⼏种关系:泛化（Generalization）：带空⼼三⾓箭头的实线来表⽰，箭头由⼦类指向⽗类实现（Realization）：带空⼼的三⾓箭头的虚线来表⽰，箭头从实现类指向接⼝关联（Association)：分为双向关联和单向关联，其中，双向关联可以⽤带两个箭头或者没有箭头的实线来表⽰，单向关联⽤带⼀个箭头的实线来表⽰，箭头从使⽤类指向被关联的类，还可以再关联线的两端标注⾓⾊名，补充说明它们的⾓⾊。
聚合（Aggregation），⽤带空⼼菱形的实线表⽰，菱形指向整体组合(Composition)：⽤带实⼼菱形的实线来表⽰，菱形指向整体。
依赖(Dependency)：使⽤带箭头的虚线表⽰，箭头从使⽤类指向被依赖的类下图为类之间的关系在UML中的图形表达式：2.1泛化泛化(Generalization)表⽰类与类之间的继承关系，接⼝与接⼝之间的继承关系，或类对接⼝的实现关系(1)继承介绍：继承表⽰是⼀个类（称为⼦类、⼦接⼝）继承另外的⼀个类（称为⽗类、⽗接⼝）的功能，并可以增加它⾃⼰的新功能的能⼒。
表⽰⽅法：继承使⽤空⼼三⾓形+实线表⽰。
⽰例：鸟类继承抽象类动物(2)实现实现表⽰⼀个class类实现interface接⼝（可以是多个）的功能。
UML类图说明
UML类图说明1：⽰例这是⼀个使⽤UML表⽰的类图的结构，通过箭头，菱形，实线以及虚线来代表⼀些类之间的关系，后⾯将按照上⾯的例⼦⼀⼀介绍说明。
上图中，abstract 车是⼀个抽象类。
⼩汽车和⾃⾏车是继承了车的抽象类，实现了抽象类的⼀些抽象⽅法，他们之间是实现关系。
SUV继承⼩汽车，SUV和⼩汽车之间是泛化关系！轮胎，发动机和⼩汽车之间是组合关系。
学⽣和班级之间是聚会关系。
学⽣和⾝份证之间是关联关系。
学⽣和⾃⾏车之间是依赖关系。
2：具体分析2.1：泛化关系上⾯UML图中，SUV和⼩汽车之间是⼀种泛化关系，SUV is a ⼩汽车，泛化关系⽤⼀种带有空⼼的箭头来表⽰。
在代码中表现的⽅式就是继承⾮抽象类的⽅式。
2.2：实现关系上⾯UML图中，⼩汽车，⾃⾏车与抽象类车，之间是⼀种实现关系。
重要的是要继承抽象类，或者实现接⼝这种关系是实现关系，在UML类图中使⽤虚线带箭头。
在代码中表现的⽅式就是继承抽象类。
2.3：聚合关系上⾯UML图中，学⽣和班级之间是⼀种聚合关系，表⽰班级有学⽣聚合⽽来，采⽤实线空⼼菱形箭头表⽰。
与组合关系不同的是，整体和部分不是强依赖的，即使整体不存在了，部分仍然存在；例如，班级撤销了，学⽣不会消失，他们依然存在。
2.4：组合关系上⾯UML图中，轮胎，发动机和⼩汽车之间是⼀种组合关系，采⽤实线实⼼菱形箭头表⽰。
与聚合关系不同的是，整体和部分是强依赖的，即使整体不存在了，组合部分也不存在；例如，⼩汽车没有，⾃然轮胎和发动起，也不会存在了。
2.5：关联关系上⾯UML图中，学⽣和⾝份证是⼀种关联关系。
关联关系是⽤⼀条直线表⽰的；它描述不同类的对象之间的结构关系；它是⼀种静态关系，通常与运⾏状态⽆关，⼀般由常识等因素决定的；它⼀般⽤来定义对象之间静态的、天然的结构；所以，关联关系是⼀种“强关联”的关系；⽐如，乘车⼈和车票之间就是⼀种关联关系；学⽣和学校就是⼀种关联关系；2.6：依赖关系上⾯UML图中，学⽣和⾃⾏车之间是⼀种依赖关系。
UML 类图详解
UML类图在UML的静态机制中类图是一个重点，它不但是设计人员关心的核心，更是实现人员关注的核心。
建模工具也主要根据类图来产生代码。
类图在UML的9个图中占据了一个相当重要的地位。
James Rumbaugh对类的定义是：类是具有相似结构、行为和关系的一组对象的描述符。
类是面向对象系统中最重要的构造块。
类图显示了一组类、接口、协作以及他们之间的关系。
在UML中问题域最终要被逐步转化，通过类来建模，通过编程语言构建这些类从而实现系统。
类加上他们之间的关系就构成了类图，类图中还可以包含接口、包等元素，也可以包括对象、链等实例。
接口在类图中通过版型来表示<<interfac e>>，下面的介绍将主要介绍类，接口和类类似。
A. 类的UML表示类的命名尽量应用领域中的术语，应明确、无岐义，以利于相互交流和理解。
类的属性、操作中的可见性使用＋、#、－分别表示public、protected、private。
B.类之间的关系类之间的关系是类图中比较复杂的内容。
有关联、聚合、组合、范化、依赖。
关联：是模型元素之间的一种语义联系，是类之间的一种很弱的联系。
关联可以有方向，可以是单向关联，也可以是双向关联。
可以给关联加上关联名来描述关联的作用。
关联两端的类也可以以某种角色参与关联，角色可以具有多重性，表示可以有多少个对象参与关联。
可以通过关联类进一步描述关联的属性、操作以及其他信息。
关联类通过一条虚线与关联连接。
对于关联可以加上一些约束，以加强关联的含义。
如下图所示：聚合是一种特殊的关联，聚合表示整体与部分的关系。
通常在定义一个整体类后，再去分析这个整体类的组成结构。
从而找出一些组成类，该整体类和组成类之间就形成了聚合关系。
例如舰队是由一系列的舰船组成。
需求描述中“包含”、“组成”、“分为….部分”等词常意味着聚合关系。
组合也是一种特殊的关联，也表示类之间整体和部分的关系，但是组合关系中部分和整体具有统一的生存期。
Python设计模式-UML-类图（ClassDiagram）
Python设计模式-UML-类图（ClassDiagram）简介类图是⾯向对象分析和设计的核⼼，⽤来描述系统各个模块中类与类之间、接⼝与接⼝之间、类与接⼝之间的关系，以及每个类的属性、操作等特性，⼀般在详细设计过程中实施。
类图本⾝就是现实世界的抽象，是对系统中各种概念进⾏建模，并描绘出它们之间的关系，所以类图关注的对象就是元素及元素之间的关系。
类图建模步骤 - 抽象出类实体 - 识别出类的主要属性 - 画出类之间的关系 - 对各个类进⾏分析、梳理、设计类图的元素类图中包含以下⼏种模型元素：类、接⼝、关系、协作、注释、约束、包。
类 在UML的图形表⽰中，类的表⽰法是⼀个矩形，有三格组成，分别是类名、类属性、类操作。
抽象类中的类名及抽象⽅法都⽤斜体表⽰。
- 类名：⾸字母⼤写 - 类属性：格式为可见性属性名：类型 =默认值，如-name: String 可见性包括四种： + public - private # protected * package 属性名：单字属性名⼩写；多字属性名出第⼀个单词外其余单词的⾸字母⼤写 - 类操作：格式为可见性操作名(参数)：返回值类型，如+getName(): String接⼝ 在UML的图形表⽰中，接⼝的表⽰法是分为两种：圆形表⽰法和构造型表⽰法。
接⼝由两栏组成，第⼀栏顶端是接⼝名称，第⼆栏是接⼝⽅法。
接⼝⽆属性只包含操作，且没有对外可见的关联。
- 圆形表⽰法 - 构造型表⽰法关系类图中类与类之间有泛化、依赖、关联、聚合、组合关系；接⼝与接⼝之间有继承关系；类与接⼝之间有实现关系。
这些关系本⾝就是类图中的元素，⽤不同的连线表⽰。
- 泛化关系 - 依赖关系 - 关联关系 - 聚合关系 - 组合关系 - 实现关系 类图中的关系较为复杂，以下分别详述。
协作 协作是指⼀些类、接⼝、关系等元素提供的交互⾏为，能够协助其他元素执⾏活动、实现功能的辅助类。
注释 对某些类和接⼝进⾏注释。
UML类图符号各种关系说明以及举例
UML类图符号各种关系说明以及举例UML中描述对象和类之间相互关系的⽅式包括：依赖（Dependency），关联（Association），聚合（Aggregation），组合（Composition），泛化（Generalization），实现（Realization）等。
依赖（Dependency）：元素A的变化会影响元素B，但反之不成⽴，那么B和A的关系是依赖关系，B依赖A；类属关系和实现关系在语义上讲也是依赖关系，但由于其有更特殊的⽤途，所以被单独描述。
uml中⽤带箭头的虚线表⽰Dependency关系，箭头指向被依赖元素。
泛化（Generalization）：通常所说的继承（特殊个体 is kind of ⼀般个体）关系，不必多解释了。
uml中⽤带空⼼箭头的实线线表⽰Generalization关系，箭头指向⼀般个体。
实现（Realize）：元素A定义⼀个约定，元素B实现这个约定，则B和A的关系是Realize，B realize A。
这个关系最常⽤于接⼝。
uml 中⽤空⼼箭头和虚线表⽰Realize关系，箭头指向定义约定的元素。
关联（Association）：元素间的结构化关系，是⼀种弱关系，被关联的元素间通常可以被独⽴的考虑。
uml中⽤实线表⽰Association 关系，箭头指向被依赖元素。
聚合（Aggregation）：关联关系的⼀种特例，表⽰部分和整体（整体 has a 部分）的关系。
uml中⽤带空⼼菱形头的实线表⽰Aggregation关系，菱形头指向整体。
组合（Composition）：组合是聚合关系的变种，表⽰元素间更强的组合关系。
如果是组合关系，如果整体被破坏则个体⼀定会被破坏，⽽聚合的个体则可能是被多个整体所共享的，不⼀定会随着某个整体的破坏⽽被破坏。
uml中⽤带实⼼菱形头的实线表⽰Composition关系，菱形头指向整体。
1.1.1 依赖（Dependency）:虚线箭头表⽰1、依赖关系也是类与类之间的联结2、依赖总是单向的。
UML各种图总结-精华
UML各种图总结-精华UML（UnifiedModelingLanguage）是一种统一建模语言，为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。
下面将对UML的九种图+包图的基本概念进行介绍以及各个图的使用场景。
一、基本概念如下图所示，UML图分为用例视图、设计视图、进程视图、实现视图和拓扑视图，又可以静动分为静态视图和动态视图。
静态图分为：用例图，类图，对象图，包图，构件图，部署图。
动态图分为：状态图，活动图，协作图，序列图。
1、用例图（UseCaseDiagrams）：用例图主要回答了两个问题：1、是谁用软件。
2、软件的功能。
从用户的角度描述了系统的功能，并指出各个功能的执行者，强调用户的使用者，系统为执行者完成哪些功能。
2、类图（ClassDiagrams）：用户根据用例图抽象成类，描述类的内部结构和类与类之间的关系，是一种静态结构图。
在UML类图中，常见的有以下几种关系:泛化（Generalization）,实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)。
各种关系的强弱顺序：泛化=实现>组合>聚合>关联>依赖2.1.泛化【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何继承父类的所有特征和行为。
例如：老虎是动物的一种，即有老虎的特性也有动物的共性。
2.2.实现【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现。
2.3.关联【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。
双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。
【代码体现】：成员变量2.4.聚合【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。
软件工程的23种设计模式的UML类图
软件工程的23种设计模式的UML类图0 引言谈到设计模式，绝对应该一起来说说重构。
重构给我们带来了什么？除了作为对遗留代码的改进的方法，另一大意义在于，能够让我们在写程序的时候能够不需事先考虑太多的代码组织问题，当然这其中也包含了应用模式的问题。
尽管大多数开发者都已经养成了写代码前先从设计开始的习惯，但是，这种程度的设计，涉及到到大局、到总体架构、到要紧的模块划分我觉得就够了。
换句话说，这时就能写代码了。
这就得益于重构的思想了。
假如没有重构的思想，有希望获得非常高质量的代码，我们就不得不在开始写代码前考虑更多事实上并非非常稳固的代码组织及设计模式的应用问题，那开发效率当然就大打折扣了。
在重构与设计模式的合理应用之下，我们能够相对较早的开始写代码，并在功能尽早实现的同时，不断地通过重构与模式来改善我们的代码质量。
因此，下面的章节中，在谈模式的同时，我也会谈谈关于常用的这些模式的重构成本的懂得。
重构成本越高意味着，在遇到类似的问题情形的时候，我们更应该提早考虑应用对应的设计模式，而重构成本比较低则说明，类似的情形下，完全能够先怎么方便，怎么快怎么写，哪怕代码不是很优雅也没关系，回头再重构也很容易。
1 创建型1.1FactoryMethod思想：Factory Method的要紧思想是使一个类的实例化延迟到其子类。
场景：典型的应用场景如：在某个系统开发的较早阶段，有某些类的实例化过程，实例化方式可能还不是很确定，或者者实际实例化的对象（可能是需要对象的某个子类中的一个）不确定，或者者比较容易变化。
如今，假如直接将实例化过程写在某个函数中，那么通常就是if-else或者select-case代码。
假如，候选项的数目较少、类型基本确定，那么这样的if-else还是能够同意的，一旦情形变得复杂、不确定性增加，更甚至包含这个构造过程的函数所在的类包含几个甚至更多类似的函数时，这样的if-else代码就会变得比较不那么容易保护了。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
23种设计模式UML 类图及对应示例代码(一)
1.DoFactory.GangOfFour.Abstract.Structural
Abstract Factory：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
工厂模式：客户类和工厂类分开。
消费者任何时候需要某种产品，只需向工厂请求即可。
消费者无须修改就可以接纳新产品。
缺点是当产品修改时，工厂类也要做相应的修改。
如：如何创建及如何向客户端提供。
Code
2.DoFactory.GangOfFour.Adapter.Structural
Adapter：将一个类的接口转换成客户希望的另一个接口，使得原来由于接口不兼容而不能一起工作的那些类可以一起工作。
适配器(变压器)模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。
适配类可以根据参数返还一个合适的实例给客户端。
Code
3.DoFactory.GangOfFour.Bridge.Structural
Bridge：将抽象部分与它的实现部分分离，使之可以独立变化。
桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。
Code
4.DoFactory.GangOfFour.Builder.Structural
Builder:将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
建造者模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。
建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。
建造模式可以强制实行一种分步骤进行的建造过程。
Code
5.DoFactory.GangOfFour.Chain.Structural
Chain of Responsibility：为解除请求的发送者和接收者之间的耦合，而使多个对象有机会处
理这个请求。
将这些请求连成一个链，并沿着这条链传递该请求，直到有个对象处理它。
责任链模式：在责任链模式中，很多对象由每一个对象对其下家的引用而接起来形成一条链。
请求在这个链上传递，直到链上的某一个对象决定处理此请求。
客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户端的情况下动态的重新组织链和分配责任。
处理者有两个选择：承担责任或者把责任推给下家。
一个请求可以最终不被任何接收端对象所接受。
Code
mand.Structural
Command：将一个请求封装为一个对象，从而使你可以用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可以取消的操作。
命令模式：命令模式把一个请求或者操作封装到一个对象中。
命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。
命令模式允许请求的一方和发送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否执行，何时被执行以及是怎么被执行的。
系统支持命令的撤消。
Code
posite.Structural
Composite：将对象组合成树形结构以表示“部分－整体”的层次结构。
Composite使得客户对单个对象和复合对象的使用具有一致性。
合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。
合成模式就是一个处理对象的树结构的模式。
合成模式把部分与整体的关系用树结构表示出来。
合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。
Code
8. DoFactory.GangOfFour.Decorator.Structural
Decorator：动态地给一个对象添加一些额外的职责。
就扩展功能而言，Decorator模式比生成子类方式更加灵活。
装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。
动态给一个对象增加功能，这些功能可以再动态的撤消。
增加由一些基本功能的排列组合而产生的非常大量的功能。
Code
9.DoFactory.GangOfFour.Facade.Structural
Facade：为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，使得这个子系统更加容易使用。
门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。
门面模式提供一个高层次的接口，使得子系统更易于使用。
每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。
但整个系统可以有多个门面类。
Code
10.DoFactory.GangOfFour.Factory.Structural
Factory Method：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。
Factory Method让一个类的实例化延迟到子类。
工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。