2015-OO-设计模式(1)(2)
设计模式（1）
4 用GoF设计模式设计用例实现
1. 2. 3. 4. 5. 6. 7.
适配器模式（GoF） 工厂模式（GoF） 单子模式（GoF） 策略模式（GoF） 组合模式（GoF） 外观模式（GoF） 观察者/发布－订阅/委托事件模式 （GoF）
《create》 Some App 《create》
<<Interface>> Shape
Square
Circle
15
4 用GoF设计模式设计用例实现2－工厂模式
改进：工厂模式允许我们只依赖于抽象接口就能创建出 具体类的实例。
public interface ShapeFactory { public Shape make(String shapeName) throws Exception; }
20
4 用GoF设计模式设计用例实现3－单子模式 Register对工厂类的调用：
public class Register { IAccountingAdapter accountingAdapter； public void initialize() { do some work ... accountingAdapter = ServicesFactory.getlnstance().getAccountingAdapter(); do some work ... } // other methods... }
4 用GoF设计模式设计用例实现2－工厂模式 –问题：当考虑某些特殊情况时，如复杂的创 建逻辑、希望分离创建职责以产生更好的内 聚度等，谁应该负责创建对象？ –解决方案：创建一个名为工厂的纯虚构对象 来处理创建。
{ if ( taxCalculatorAdapter == null )
类型？ 返回值类型？
6。工厂中如何与具体适配器类解耦 1）具体用哪个适配器？用属性来记录 System.setProperty("name","zhouchunyan") System.setProperty("", "TaxAAdaptor"); 2）工厂中的getTaxCalculatorAdaptor与具体适配器解耦 ITaxCalculatorAdaptor getTaxCalculatorAdaptor() { if(taxCalculatorAdaptor==null) { String className=System.getProperty(""); taxCalculatorAdaptor=Class.forname(className).newinstance() } return taxCalculatorAdaptor; }
ServicesFactory具有全局可见性
21
4 用GoF设计模式设计用例实现3－单子模式
通过单子模式 得到该实例的 可见性
ServicesFactory.getlnstance().getAccountingAdapter();
22
4 用GoF设计模式设计用例实现－外部接口变化的解决方案
register向外部SAP财务系统发送PostSale
17
4 用GoF设计模式设计用例实现3－单子模式
3.单子模式
–谁创建工厂类？如何访问此类？ –事实：整个程序只需要一个工厂类的实例； 由于代码在不同的地方需要访问适配器以调 用外部系统的服务，所以工厂类的方法也需 要在代码的多个地方被调用。 –问题：一个类X只能有一个实例（这就是“单 子”的含义)。对象需要全局的可见性和单一 的访问点。 –解决方案：为类X定义静态方法getInstance， 该方法返回X的唯一实例。因为是静态方法， 所以可以全局访问，且该类的构造方法可见 性设为私有（private）。
代码中有两个容易变化的 地方：计算器的类名、计 算器提供的方法名
2。使用适配器来屏蔽接口的差异 class TaxAdaptor { TaxA tax=new TaxA(); float getTaxes() 3。代码变为 { TaxAdaptor adaptor ; return tax.tax(); adaptor =new TaxAAdaptor(); } adaptor.getTaxes(...);
现在，就剩红色字体处 要出来啦~ 继续想办法！
4 用GoF设计模式设计用例实现
1.适配器模式
–问题：如何解决接口不兼容的问题或为不同 接口但相似的组件提供一个稳定的接口？ –解决方案：通过一个中间的适配器对象将组 件的原来接口转换为另一个接口。
6
4 用GoF设计模式设计用例实现-适配器模式 适配器模式类图
taxCalculatorAdaptor= (ITaxCalculatorAdaptor)Class.forName(className).newInstance(); } return taxCalculatorAdaptor; }
14
4 用GoF设计模式设计用例实现2－工厂模式
补充 依赖倒置原则(DIP)告诉我们应该优先依赖于抽象类， 而避免依赖于具体类。当这些具体类不稳定时，更应该 如此。 因此，下面的代码违反了这个原则 Circle c = new Circle();
13
4 用GoF设计模式设计用例实现2－工厂模式
注意：工厂方法返回对 象的类型是接口，而不 是类，这样工厂方法就 可以返回接口的任何实 现。
{
注意：在serviceFactory中，决定哪个类的实例 被初始化是从外部数据源读入类名（如在java 中可使用系统属性），然后动态装载此类来实
if(taxCalculatorAdaptor==null) 现的。 { String className=System.getProperty("");
10
5。应用工厂模式来屏蔽具体适配器 ITaxCalculatorAdaptor adaptor; ServiceFactory factory=new ServiceFactory(); 现在，代码彻底和具体 adaptor =factory.getTaxCalculatorAdaptor(); 的适配器类无关啦~~ adaptor.getTaxes(...);
18
4 用GoF设计模式设计用例实现3－单子模式
//单子方法getlnstance返回工厂类的唯一实例
public static synchronized ServicesFactory getlnstance() { if ( instance == null ) instance = new ServicesFactory(); return instance;
9
4 用GoF设计模式设计用例实现2－工厂模式
2.工厂模式
–考虑：在前面外部服务适配器解决方案中， 谁去负责创建这些适配器？谁去确定要创建 的是哪个适配器，是TaxMasterAdapter 还是
GoodAsGoldTaxProAdapter？
–让领域类（如Sale）来创建适配器对象是否 合适？--如此则领域类不只是包含应用逻辑 了！ –一个设计原则：设计要保证分离不相关的事 物。分离不同的事物到不同的领域，从而使 得分离的各部分能达到高内聚的设计目标。
}
接口统一了，但是代码 还是和具体的类耦合！ 继续想办法！
TaxBdaptor adaptor ; adaptor =new TaxBAdaptor(); adaptor.getTaxes(...);
4。创建适配器的抽象来屏蔽不同的适配器 ITaxCalculatorAdaptor adaptor ; adaptor =new TaxAAdaptor(); adaptor.getTaxes(...); ITaxCalculatorAdaptor adaptor ; adaptor =new TaxBAdaptor(); adaptor.getTaxes(...);
–register从工厂类中获取针对SAP财务系统的适配器 SAPAccountingAdaptor； –Register向SAPAccountingAdaptor发送PostSale消 息，由适配器将消息适配后转发给外部SAP财务系统。
请画出以上交互的顺序图
23
4 用GoF设计模式设计用例实现－外部接口变化的解决方案
19
4 用GoF设计模式设计用例实现3－单子模式
Synchronized解释：单子类的 getInstance方法经常被调用，在多线程 （MultiThread）的应用程序里，在某一 客户端线程调用getInstance方法前，必 须先把该方法锁住，以防止其他客户端调 用该方法；当方法调用完毕后，再把锁打 开，让其他客户端线程可以调用该方法。 从而实现线程的并发控制。
适配器模式、多态模式、工厂模式、单子模式的综合运用
24
4 用GoF设计模式设计用例实现4－策略模式
目的：实现复杂的定价规则。
–商店的定价策略可能变化。对变化的定价算 法我们应如何设计？
策略模式
–语境/问题：如何对变化或与变化相关的算法 或策略进行设计？如何设计系统使得其具有 改变算法或策略的能力？ 解决方案：在单独的类中分别定义每种算法、 策略和政策，并且使其具有公共接口。
16
4 用GoF设计模式设计用例实现2－工厂模式
public class ShapeFactoryImplementation implements ShapeFactory { public Shape make(String shapeName) throws Exception { if (shapeName.equals("Circle")) return new Circle(); else if (shapeName.equals("Square")) return new Square(); else throw new Exception("ShapeFactory cannot create " + shapeName); } }
OO设计原则(1)
OO设计原则（一）好的作品来源于好的设计，那么好的设计又来自于哪里？且看OO设计中最常用的几大原则了。
单一职责原则（SPR）核心思想：一类不二用，一个类，最好只要专注于一件事，且只有一个引起它变化的原因。
它强调的是对职责的分离，是模块间保持低耦合，高聚合的一个关键。
下面就来看一下对比，亲身感受一下SPR。
对数据库的操作经常是违背该设计原则的重灾区。
比如当只有符合权限的用户才能对数据进行添加操作时，我们一般会在对数据操作之前对用户身份进行判别。
很多时候我们就会直接写代码如下：Class DBManager{pubic void Add(){If(Permission(userName) == true){Console.WriteLine(“用户可以对数据进行添加”);}public bool Permission(string UserName){//处理权限判断}}}初看可能并没有什么问题，但是仔细看就会发现，在以上设计中，DBManager类将对数据库的操作和对用户权限的判别封装在一起实现。
这样子，现在可能没多大问题，但如果以后对权限的设置规则发生改变的话，那可就有得玩了，你可能得把所有的数据库操作逻辑都重新修改。
这时，你就应该想到要遵循SPR设计原则对其修改了。
修改后如下：//用接口定义有哪些操作public interface IDB Operation{Add();bool Delete();……}//而DBManager只关注数据的操作public class DBManager: IDB Operation{public void Add(){//执行数据增加}}通过以上重构，实现了职责的分离，DBManager类在此只关注数据操作，而将权限判断逻辑交给下面的DBManagerProxy代理类来完成。
public class DBManagerProxy: IDB Operation{private IDB Operation m_dbManager;public DBManagerProxy(IDB Operation dbOperation){m_dbManager = dbOperation;}public bool Permission(string UserName){//处理权限判断}public void Add(){if(Permission(userName) == true){m_dbManager.Add();}}}通过此代理，我们将数据操作和权限判断两个职责分离了开来，而实际的数据操作则由DBManager来完成，这样你会发现客户端的调用也将变得相当简单：public class DBClient{public static void Main(){IDB Operation DBManager = new DBManagerProxy(new DBManager(userName))DBManager.Add();}}自此，DBManger将只有数据操作的变更这个会引起变化的原因，而权限的变更和修改则就不会对anger造成任何影响了。
OO系统分析员之路--用例分析系列(1)--什么是用例
偶然发现这个社区，发一篇较早前写的文章。
若大家觉得还有点帮助作用，我将继续发后续几篇。
我发现，在OO和UML几乎一统天下的今天，仍有很多系统分析员对OO和UML一知半解，甚至包括很多已经使用了很久UM L的系统分析员。
于是打算写一个系列文章，将多年来的工作经验做一个总结。
对初学者起个启蒙作用，也希望抛砖引喻，与各路大虾共同探讨，共同提高。
这个系列文章将以我对OO和系统分析的理解为主，从UM L基础开始，阐述面向对象的需求分析方法，过程，并以RUP 为例，阐述如何将OO过程与软件过程有机结合在一起，做一个真正OO应用。
好了，今天是第一篇。
想得很远，真希望我能坚持下去，呵呵用例是什么？其原始英文是usecase，直译过来就成了用例。
这也是一个比较贴切的叫法了，从字面的直接理解就是使用的例子。
另一种比较流行的定义是用例就是与使用者(actor)交互的，并且给使用者提供可观测的有意义的结果的一系列活动的集合。
这个定义还是比较费解的，笔者在众多应聘者中发现很多使用用例来做需求的系统分析员，有的已经使用了两年以上，但仍不能把握用例的本质，虽然他们号称精通UML。
最具普遍意义的理解错误是认为用例就是功能的划分和描述，认为一个用例就是一个功能点。
在这种理解下，用例变成了仅仅是较早前需求中功能框图的翻版，很多人用用例来划分子系统，功能模块和功能点。
如果这样，用例根本没有存在的必要。
有意思的是，造成这种理解错误的相当一部分原因却是因为对OO思想的理解不够深入，本质上说，把用例当成功能点的系统分析员脑子里还是面向过程的那一套思想，虽然他们在使用OO的工具，OO的语言，号称在做面向对象的开发，但过程的影子还没有从他们脑子里彻底抹去。
如果用例不是功能的话，它是什么呢？从定义上说，能给使用者提供一个执行结果的活动，不就是功能吗？我的回答是：错！功能是计算机术语，它是用来描述计算机的，而非定义需求的术语。
功能实际描述的是输入-->计算-->输出。
OO设计原则
OO设计原则在软件软件系统中，一个模块设计得好不好的最主要、最重要的标志，就是该模块在多大程度上将自己的内部数据和其他与实现有关的细节隐藏起来。
一个设计得好的模块可以将它所有的实现细节隐藏起来，彻底地将提供给外界的API和自己的实现分隔开来。
这样一来，模块与模块之间就可以仅仅通过彼此的API相互通信，而不理会模块内部的工作细节。
OO设计根本的指导原则是提高可维护性和可复用性。
这些原则主要有：1. 开闭原则一个软件实体应该对扩展开放，对修改关闭。
在设计一个模块的时候，就当使这个模块可以在不被修改的前提下被扩展。
换言之，就当可以在不必修改源代码的情况下改变这个模块的行为。
如何做到既不修改，又可以扩展？解决问题的关键在于抽象化：在Java语言里，可以给出一个或多个抽象Java类或Java接口，规定出所有的具体类必须提供的方法特征作为系统设计的抽象层。
这个抽象层预见了所有的可能扩展，因此，在任何扩展情况下都不会改变。
这就使得系统的抽象层不需要修改，从而满足了—对修改关闭。
同时，由于从抽象层导出一个或多个新的具体类可以改变系统的行为，因此系统的设计对扩展是开放的。
开闭原则实际上是对“对可变性的封闭原则“：找到一个系统的可变因素，将之封装起来。
这个原则意昧着两点：1) 一个可变性不应当散落在代码的很多角落里，而应当被封装到一个对象里面。
同一种可变性的不同表象意昧着同一个继承等级结构中的具体子类。
继承就当被看作是封装变化的方法，而不应当被认为是从一般的对象生成特殊对象的方法。
2) 一种可变性不应当与另一种可变性混合在一起。
（所有类图的继承结构一般不会超过两层，不然就意昧着将两种不同的可变性混合在了一起。
）开闭原则是总的原则，其它几条是开闭原则的手段和工具。
2. 依赖倒转原则依赖倒转原则讲的是：要依赖于抽象，不要信赖于实现。
开闭原则是目标，而达到这一目标的手段是依赖倒转原则。
抽象层次包含的是应用系统的商务逻辑和宏观的、对整个系统来说重要的战略性决定，是必然性的体现；而具体层次则含有一些次要的与实现有关的算法和逻辑，以及战术性的决定，带有相当大的偶然性选择。
深圳大学课程教学大纲-深圳大学计算机与软件学院
深圳大学课程教学大纲课程编号: 1500300001 课程名称: 软件体系结构开课院系: 计算机与软件学院网络软件工程系制订(修订)人: 毛斐巧审核人: 批准人：2015年3月17日制(修)订课程名称: 软件体系结构英文名称: Software Architecture总学时: 54 其中:实验课 18学时学分: 2.5先修课程: 面向对象系统分析与设计、统一建模语言教材:刘伟.设计模式,清华大学出版社,2011参考教材:[1]《设计模式实训教程》，刘伟著，清华大学出版社课程性质: □综合必修□专业必修■专业选修□全校公选教学目标:开设本课程的目的是为建立一个基于模式的软件体系结构概念，从而为正确地分析和构建实际的复杂软件系统奠定坚实的基础。
学生在完成本课程学习后，应能够：1.理解软件体系结构的相关概念；2.掌握如何将复杂的软件系统按产品特征划分为子系统，以及如何规范子系统的构成；3.掌握如何应用模式的方法构造复杂软件的解决方案；4.掌握一些常见设计模式的应用环境及解决的问题，并能在实践中根据需要应用这些模式。
课程简介:《软件体系结构》主要是为软件工程/计算机专业的高年级本科学生，特别是软件工程方向的学生所开设的课程。
本课程系统地介绍软件体系结构的基本原理、方法和实践，介绍软件体系结构的设计和应用实例，强调理论与实践相结合。
本课程重点讲解基于模式的软件体系结构描述方法、软件体系结构风格和设计模式、基于产品特征的软件开发/重构方法、设计模式作为解决方案空间的有效工具等内容。
软件体系结构的模式描述、产品特征表达与模式设计和重构、在实践中如何应用产品特征来划分和规范子系统等内容是本课程的难点。
本课程采用课堂讲解与课程实验相结合的方法，辅以一定的案例讲解，帮助学生加强理解，更好地掌握课程内容。
教学内容：本课程内容共分6部分：1．软件体系结构概念主要讲授软件体系结构的发展历程和基本概念、软件体系结构设计的基本原理、研究软件体系结构的意义、当前研究状况等内容。
JAVA中OOD设计模式
UML类图结构
解释：
• Abstract Factory模式通过抽象工厂为客户（调用 者）生成多类产品， 其中抽象工厂负责管理子工厂对象，子工厂负责生成 某一类具体的产品对象
2 设计原则
• OCP－－开闭原则
描述： - 对扩展开放（open） - 对修改关闭（closed）
OCP解释
• 原因：
DIP－－依赖倒置原则
• 描述：
A. 高层模块不应该依赖于低层模块，二者都应该 依赖于抽象 B. 抽象不应该依赖于细节，细节应该依赖于抽 象
DIP具体描述：
• High Level Classes（高层模块）
Abstraction Layer（抽象接口层） Low Level Classes（低层模块）
此章或ood中涉及到的接口都是指广义的代表抽象类和接口dip高层模块不应该依赖于低层模块二者都应该依赖于抽象highlevelclasses高层模块abstractionlayer抽象接口层lowlevelclasses低层模块uml类图结构dip解释抽象接口是对低层模块的抽象低层模块继承或实现该抽象接口
2 Head First 系列之
Java设计模式
设计模式介绍
• (1)创建型模式
• (2)构造型模式 • (3)行为模式
(1)创建模式：
• A 简单工厂模式(Simple Factory) －－不是模式的模式 • 描述： 用于封装创建对象的代码
B 工厂（方法）模式(Factory Method)
Method ,请给出2种的实现.
引申思考?
• 3 Parameterized Factory Method 设计模式 中,如果用户输入的参数不正确或者没有相应的 product,怎么解决?
0面向对象范式-基本概念介绍
上述目标的设计评估范式
设计效果评估：（副作用和时间成本） 设计效果评估：（副作用和时间成本） ：（副作用和时间成本 1、维护范式（修改类）：变化局部，稳定全局；变与 、维护范式（修改类）：变化局部，稳定全局； 不变的平衡，将变化的代码从不变的代码中分开， 不变的平衡，将变化的代码从不变的代码中分开，然后封 装在一个类中，这样将来修改代码时就只需要修改一个类， 装在一个类中，这样将来修改代码时就只需要修改一个类， 将变化封装起来。还包括通过接口、 将变化封装起来。还包括通过接口、抽象类来隔离客户端 与服务类之间的变化 2、扩展范式（如何扩展才能适应变化，这种扩展会带来 、扩展范式（如何扩展才能适应变化， 副作用吗？）：变化具体，稳定抽象； 副作用吗？）：变化具体，稳定抽象；通过继承和接 口实现来进行扩展。 口实现来进行扩展。 3、复用范式：重复使用的性能（继承复用、组合复用、 、复用范式：重复使用的性能（继承复用、组合复用、 分离复用） 分离复用）稳定可重用资产--一个类或一组类可以
面向对象软件变化与稳定的平衡设计艺术
欢迎来到设计模式世界
所有C++ 界、Java 界、C#界 等主流面 向对象世 界的人们 都需要… 站在巨人 的肩膀上， 我们就能 做设计！
2
什么学习 学习设计模式 为什么学习设计模式
设计模式 --不用重复设计 不用重复设计
5.2类关系、UML表示与代码模型映射 类关系、 类关系 表示与代码模型映射
继承（泛化） （接口）实现 关联
聚合 组合
依赖
5.2继承 接口与代码模型映射 继承/接口与代码模型映射 继承
接口 Public interface IA{
Public void op1(); Public void op2();
OO设计模式和设计原则
1.1 设计正在“腐烂”的征兆（Symptoms of Rotting Design）有四个主要的征兆告诉我们该软件设计正在“腐烂”中。
它们并不是互相独立的，而是互相关联，它们是过于僵硬、过于脆弱、不可重用性和粘滞性过高。
1. 过于僵硬Rigidity Rigidity 致使软件难以更改，每一个改动都会造成一连串的互相依靠的模块的改动，项目经理不敢改动，因为他永远也不知道一个改动何时才能完成。
2. 过于脆弱Fragility Fragility 致使当软件改动时，系统会在许多地方出错。
并且错误经常会发生在概念上与改动的地方没有联系的模块中。
这样的软件无法维护，每一次维护都使软件变得更加难以维护。
（恶性循环）3. 不可重用性immobility immobility 致使我们不能重用在其它项目中、或本项目中其它位置中的软件。
工程师发现将他想重用的部分分离出来的工作量和风险太大，足以抵消他重用的积极性，因此软件用重写代替了重用。
4. 粘滞性过高viscosity viscosity有两种形式：设计的viscosity和环境的viscosity.当需要进行改动时，工程师通常发现有不止一个方法可以达到目的。
但是这些方法中，一些会保留原有的设计不变，而另外一些则不会（也就是说，这些人是hacks）。
一个设计如果使工程师作错比作对容易得多，那么这个设计的viscosity 就会很高。
环境的viscosity高是指开发环境速度很慢且效率很低。
2 面向对象的类设计原则2.1 开放关闭原则The Open Closed Principle （OCP）A module should be open for extension but closed for modification.一个模块应该只在扩展的时候被打开（暴露模块内部），在修改的时候是关闭的（模块是黑盒子）。
在所有的面向对象设计原则中，这一条最重要。
该原则是说：我们应该能够不用修改模块的源代码，就能更改模块的行为。
运用OO设计原则：DIP和OCP
最 初 的 实现 ::Person 最 初 的 实现 ::FileReader + dataFilename: string id: int name: string
ReadFromFile() : Person[]
«Access» + Id() : int + Name() : string
软件是如何腐化的
模式遵循原则
观察者（Observer）
•
遵循DIP：Observer是一个抽象类，ConcreateObserver依赖于它，Subject的 具体方法也依赖于它。虽然Subject不具有抽象方法，但它是逻辑抽象的，绝不 应该被实例化。因此ConcreateSubject依赖于Subject也毫不违反DIP。
遵循DIP的指导原则
简单地说：“依赖于抽象”
不应该依赖于具体类，程序中所有的依赖关系都应该终止于抽象类 或接口。
具体来说：
• 任何变量都不应该持有一个指向具体类的引用。 • 任何类都不应该从具体类派生。 • 任何方法都不应该重写它的任何基类中已经实现的方法。
适当的应用DIP和OCP
使用DIP和OCP是有代价的
Person id: int name: string
«Access» + Id() : int + Name() : string
这是个遵循了结构化的设计，把相关操作封装到独立的类里面。你的程序很成 功，很快就被部署到了公司各处！
软件是如何腐化的
需求发生变化 几个月后，BOSS告诉你，对于某些部门，由于数据量比较大，他们把新 的数据改用数据库来存储了，而你需要修改程序同时支持两种读取方式。 考虑到很多其他公司的程序都在使用你的程序，你不能修改Run()的接口， 否则会导致很多的程序需要重新编译和重新测试。
24种设计模式及案例
种设计模式及事例重点时辰，第一时间送到！个人Github-24 种设计模式事例链接种设计模式案例维导图创立型模式工厂模式工厂模式（FactoryPattern）是Java中最常用的设计模式之一。
这类种类的设计模式属于创立型模式，它供应了一种创立对象的最正确方式。
在工厂模式中，我们在创立对象时不会对客户端裸露创立逻辑，并且是经过使用一个共同的接口来指向新创立的对象。
介绍企图：定义一个创立对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创立过程延缓到子类进行。
主要解决：主要解决接口选择的问题。
何时使用：我们明确地计划不一样条件下创立不一样实例时。
怎样解决：让其子类实现工厂接口，返回的也是一个抽象的产品。
重点代码：创立过程在其子类履行。
应用实例：1、您需要一辆汽车，能够直接从工厂里面提货，而不用去管这辆汽车是怎么做出来的，以及这个汽车里面的详细实现。
2、Hibernate换数据库只需换方言和驱动就能够。
长处：1、一个调用者想创立一个对象，只需知道其名称就能够了。
2、扩展性高，假如想增添一个产品，只需扩展一个工厂类就能够。
3、障蔽产品的详细实现，调用者只关怀产品的接口。
弊端：每次增添一个产品时，都需要增添一个详细类和对象实现工厂，使得系统中类的个数成倍增添，在必定程度上增添了系统的复杂度，同时也增添了系统详细类的依靠。
这其实不是什么好事。
使用处景：1、日记记录器：记录可能记录到当地硬盘、系统事件、远程服务器等，用户能够选择记录日记到什么地方。
2、数据库接见，当用户不知道最后系统采纳哪一类数据库，以及数据库可能有变化时。
3、设计一个连结服务器的框架，需要三个协议，'POP3'、'IMAP'、'HTTP'，能够把这三个作为产品类，共同实现一个接口。
注意事项：作为一种创立类模式，在任何需要生成复杂对象的地方，都能够使用工厂方法模式。
有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只需要经过new 就能够达成创立的对象，无需使用工厂模式。
设计模式(OOD)学习
设计模式（OOD）学习设计模式（Object-Oriented Design Patterns）是在软件开发中用来解决经常出现的问题的一种经验总结和方法论。
设计模式通过提供一套经过验证的解决方案来帮助开发人员更高效地设计和组织代码。
本文将介绍设计模式的概念、常见的设计模式分类以及一些常用的设计模式示例。
设计模式的概念设计模式是一种软件设计中的抽象，它描述了解决常见问题的一种方法。
它们不是一种具体的算法或代码实现，而是一种在特定情况下可重复使用的解决方案。
设计模式的目标是提高代码的可重用性、可读性和可维护性。
常见的设计模式分类常见的设计模式可以根据其目标和应用场景进行分类。
以下是几个常见的设计模式分类：1. 创建型模式（Creational Patterns）创建型模式关注对象的实例化过程。
它们提供了一种将对象的创建和使用分离的方法，隐藏了对象的创建细节。
- 单例模式（Singleton Pattern）：保证一个类只有一个实例，并提供全局访问点。
- 工厂模式（Factory Pattern）：通过使用工厂方法来创建对象，而不是直接使用new操作符。
- 抽象工厂模式（Abstract Factory Pattern）：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们的具体类。
- 原型模式（Prototype Pattern）：通过克隆现有对象来创建新对象。
- 建造者模式（Builder Pattern）：将一个复杂对象的构建过程与其表示分离，使得同样的构建过程可以创建不同的表示。
2. 结构型模式（Structural Patterns）结构型模式关注类和对象的组合，通过定义对象之间的关系来实现更大的结构。
- 适配器模式（Adapter Pattern）：将一个类的接口转换成客户希望的另一个接口。
- 装饰器模式（Decorator Pattern）：动态地将新功能添加到对象中。
- 代理模式（Proxy Pattern）：为其他对象提供一个代理以控制对这个对象的访问。