设计模式总结
设计模式（Design Patterns）笔记
如果你有一定的面向对象编程经验,你会发现其中某些设计模式你已经无意识的使用过了;如果你是一个新手,那么从开始就培养自己良好的编程习惯(让你的的程序使用通用的模式,便于他人理解;让你自己减少重复性的编程工作),这无疑是成为一个优秀程序员的必备条件.
整个设计模式贯穿一个原理:面对接口编程，而不是面对实现.目标原则是:降低耦合,增强灵活性.
一些基本的设计模式
Abstract Factory：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。（使用得非常频繁。）
Adapter：将一个类的接口转换成客户希望的另外一个接口。A d a p t e r模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
Bridge：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
Builder：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
Chain of Responsibility：为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。
Command：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。
Composite：将对象组合成树形结构以表示“部分-整体”的层次结构。它使得客户对单个对象和复合对象的使用具有一致性。
Decorator：动态地给一个对象添加一些额外的职责。就扩展功能而言， 它比生成子类方式更为灵活。
Facade：为子系统中的一组接口提供一个一致的界面， F a c a d e模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
Factory Method：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。Factory Method 使一个类的实例化延迟到其子类。
Flyweight：运用共享技术有效地支持大量细粒度的对象。
Interpreter：给定一个语言, 定义它的文法的一种表示，并定义一个解释器, 该解释器使用该表示来解释语言中的句子。
Iterator：提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。
Mediator：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
Memento：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。
Observer：定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动刷新。
Prototype：用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。
Proxy：为其他对象提供一个代理以控制对这个对象的访问。
Singleton：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
State：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。
Strategy：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。
Template Method：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method 使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
Visitor：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
前言：呵呵，拿了第一页出来，还没反应过来，就被兄弟们惨骂一顿，前面实在象目录，^_^, 不过大家别急嘛，好歹给我点休息时间。
不多说，下面开始记笔记！^_^
设计模式(Design Patterns)笔记之一：Abstract Factory
定义：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。提供创建对象的接。
工厂模式是我们最常用的模式，是用来创建对象的，它就相当于创建对象的new。
例如我们有一个类Example,我们要创建Example的对象:
Example example=new Example();
或
Example example=new Example(参数);
如果创建Example时做的事情不是如赋值这样简单的事,可能是很长一段代码,如果也写入构造
函数中,那明显的就违背了面向对象的原则.
我们需要将创建实例的责任与使用实例的责任分开, 使得
Example example=new Example(参数);
就是简单的责任:使用Example这个实例;而创建Example的任务就交给了Factory工厂模式.
按照传统方法，我们如果需要继承Example类，生成MyExample，就需要定义Example为Interface，然后，不断继承这个Interface，生成许多子类，造成以后代码维护是如此的困难。
如果，我们开始就采用了工厂模式，也许就没有这么多的烦恼了。
我们生成一个Factory，它专门负责生成Example的实例。
public class Factory {
public static Example getIntance() {
......
if(flag == 1)
return new MyExample();
if(flag == 2)
return new YourExample();
}
}
然后，那么在你的程序中,如果要实例化MyExample时.就使用
Example example=Factory.getIntance();//还有其它标志，不具体写了。
具体使用：
工厂模式有以下三种：
1. 简单工厂(Simple Factory)
2. 工厂方法(Factory Method)；
3. 抽象工厂(Abstract Factory)。
我们先看一段代码
public abstract class Factory{
public abstract MyExample creator();
public abstract YourExample creator();
}
public class FirstFactory extends Factory{
public MyExample creator(){
......
}
public YourExample creator(){
......
}
}
public class SecondFactory extends Factory{
public MyExample creator(){
......
}
public YourExample creator(){
......
}
}
这里，我们需要创建多个对象，复杂性提高，于是需要采用Abstract Factory来封装共同属性和方法，而将不同的属性和方法通过子类来实现。
简而言之，工厂模式的目的就是用来实现实例分发。
工厂模式中几种类型的一些差别：
简单工厂模式是根据参数来决定产生实例；
简单工厂模式, 核心是一个实类；
工厂方法模式的核心是一个抽象工厂类；
工厂方法模式可以允许很多实的工厂类从抽象工厂类继承下来, 从而可以在实际上成为多个简
单工厂模式的综合；
工厂方法一般只创建一个实例，而Abstract Factory创建多个实例。
前言：呵呵，从这起开始，我们换种记录方法怎么样？学学人家的，寓教于乐。第一次尝试，见笑了。^_^
定义：Adapter：将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
角色设定：
Helen，初次接触设计模式的美女程序员(没有BF)。
AndyTao，高手，战斗力达到N级，对设计模式有相当程度的了解。
问题的提出：
Helen埋首在公司自己的小空间里写着代码，（旁白：她虽然是个美女，但是写代码的水平还是不错的。）有点问题正在埋头苦想，这时，AndyTao从旁边冒出来，“嗨，美女，到点了，一起吃饭吧？”“不行，我正烦着呢！”Helen皱着眉头说。“哇，谁，谁欺负咱们Helen？？？”“切，谁敢欺负我啊。”“那怎么了？”AndyTao一副义愤填膺的样子（这小子，司马昭之心）。 “没有啦，我这里程序不好处理。”“噢，我看看！”AndyTao不知什么时候已经在Helen的身后了。
屏幕上一段代码：
public class DrawCircle {
public void DrawCircle() {
……
}
public void insert(String msg){
System.out.println("DrawCircle insert():"+msg);
}
……
}
public class DrawAngle {
public void DrawAngle() {
……
}
public void insert(String msg){
System.out.println("DrawAngle insert():"+msg);
}
……
}
“我现在要在DrawCircle中调用DrawAngle的方法，可是类的已经分发出去了，不能修改，我该怎么办？”
看着美女皱眉头的样子，AndyTao一阵心痛，“这样啊，我给你提示，再写个Adapter类吧。”“什么是Adapter？”
“呵呵，在实际编码过程中，由于某种需要，我们经常要将两个毫无关系的类交互。于是我们需要进行某种修正，修改各个类的接口，这通常不符合编码要求，而且，如果没有源代码，我们又该怎么办？于是，我们就要用到Adapter了，也就是适配器的意思。象你上面的程序，我们不能修改类接口，于是，我们再写一个Adapter类。”
public class DrawAdapter extends DrawCircle {
private DrawAngle drawangle;
public DrawAdapter(DrawAngle angle) {
this.drawangle=angle;
}
public void insert(String msg) {
drawangle.insert(str);
}
……
}
“在上面代码中，DrawAngle属于Adaptee,是被适配者。DrawAdapter是Adapter,将Adaptee(被适配者DrawAngle)和Target(目标DrawCircle)进行适配。实际上这是将组合方法(composition)
和继承(inheritance)方法综合运用的一个例子。这样，你就无需对原来的类修改，甚至无需要知道其内部结构和源代码。”
“上面我们说的是对象适配器(Object Adapter)，它允许client和Adaptee完全无关，只有适配器知道它们两者的存在。另外，还有一种是类适配器(Class Adapter)，它使用多重继承来实现。象对象适配器(Object Adapter)中，就是上个例子，DrawAdapter继承了DrawCircle，但是，DrawAdapter同样可以继承DrawAngle。由于Java不支持多重继承，这就是说，我们的某个类必须定义为接口(interface)。我们可以把DrawAngle定义为接口IDrawAngle，这样代码如下。”
public interface IDrawAngle {
public void insert(String msg);
……
}
public class DrawAngle implements IDrawAngle {
public void DrawAngle() {
……
}
public void insert(String msg){
System.out.println("DrawAngle insert():"+msg);
}
……
}
public class DrawAdapter extends DrawCircle implements IDrawAngle {
private DrawAngle drawangle;
public DrawAdapter(DrawAngle angle) {
this.drawangle=angle;
}
public void insert(String msg) {
drawangle.insert(str);
}
……
}
“看到了么，这样我们就实现了类适配器(Adapter)模式。不过，类适配器(Adapter)有一个问题，如果我们的Target和Adaptee有一个相同名字的方法，Adapter不能保证这两个方法具有相同的含义或者行为，这是非常危险的。所以要注意这种情况！”
“哦，我知道了，Adapter模式的用处就在于使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。从而解决我现在的问题。”
“美女不笨嘛。这顿你请，以后我请，嘿嘿……”
“想追我？这顿我请，以后嘛，呵呵，再说吧。谢谢，走吧。”“OK!”
欲知后事如何，请待下回。^_^
前言：不好意思，前段时间由于各方面的原因，没顾上写了。这就加油补上。^_^
概念：
Bridge：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
--------------------------------------
烈日，当空；没有一丝风，真的让人感觉透不过气来。想起去年夏天在没有空调的房子里写代码，^_^，真是对人性的一种考验。AndyTao正想着，不觉笑了。午休时间也快过了，继续写我的代码吧。
“Andy，过来帮我看看嘛！”一串银铃声传了过来。
“唉，美女相邀，怎能不动啊。”AndyTao心里想着，没敢说出口。“我说，你又怎么了？就你事多。”
“上次技术讨论会上听你说过，如果一个抽象类或者接口有多个具体的实现类（concrete subclass）的时候，为了不至于由于使用单纯继承进行抽象类或接口的具体实现而导致代码混乱
和可重用性不强，你说应当采用Bridge设计模式，这是怎么一回事啊？你看我现在这个例子采用继承不是很好吗？”
“哦，我看看。”
public interface Draw {
public void paint();
}
public class DrawCircle implements Draw {
public void paint(){
System.out.println("paint Circle");
……
}
……
}
public class DrawAngle implements Draw {
public void paint(){
System.out.println("paint Angle");
……
}
……
}
“你看看，我这里不是各干其事，做得挺好嘛。”
“呵呵，听我细细讲来。通常,当一个抽象类或接口有多个具体实现(concrete subclass),这些concrete之间关系可能有以下两种情况：第一种是，这多个具体实现之间恰好是并列关系，就像你的这段代码，有两个concrete class：画圆和画三角；这两个形状上的图形是并列的，没有相对概念上的重复,那么我们只要使用继承就可以了。……”
“别卖关子了好不好！”“……”“好啦好啦，我请你喝可乐可以吧？”
嘿嘿，奸计得逞，AndyTao继续说道，“但是，我们要考虑到第二种情况，如果我们两个或多个具体实现之间有概念重复，那么需要我们把抽象共同部分和行为共同部分各自独立开来,原来是准备放在一个接口里，现在需要设计两个接口，分别放置抽象部分和行为部分。”
“好抽象啊，我听不懂！”
“那好，我们来举个例子，嗯……，就拿可乐来说吧，我们喝的可乐有大杯和小杯之分，而又有加冰和不加冰之分，这样，如果我们采用单纯继承来实现这四个具体实现（大杯加冰，大杯不加冰，小杯加冰，小杯不加冰），那么很容易造成相互之间的概念重叠，而且代码混乱，不容易维护。所以……”
“所以，怎么？继续继续。”
“所以啊，我们就要采用Bridge模式来重新设计类的结构。如果采用Bridge模式，我们就需要定义两个接口或抽象类，为的是把抽象部分和行为部分分隔开来。”
“稍等稍等，喝口水先。”“来来来，用我的吧。”“那……，真不好意思了，嘿嘿……”
“我们就用可乐作例子吧。将可乐定义为抽象类，有一部分共同的实现代码可以放到里面，加冰和不加冰属于行为，那么我们就把它定义成为行为接口。”
“然后，我们可以实现下面的抽象类。”
public abstract class Coke {
CokeImp cokeImp;
public void setCokeImp(CokeImp cokeImp) {
this.cokeImp = cokeImp;
}
public CokeImp getCokeImp() {
return this.cokeImp;
}
public abstract void distributeCoke();
}
public abstract class CokeImp {
public abstract void distributeCokeImp();
}
“现在，我们就有了两个抽象类（或接口）。上面，Coke是抽象部分，CokeImp是定义的行为抽象类。为了实现我们所说的四种类动态结合的功能，我们需要在具体实现类上下点功夫罗。”
“这是大可乐：”
public class BigCoke extends Coke
{
public BigCoke() {}
public void distributeCoke()
{
System.out.print("BigCoke ");
CokeImp cokeImp = this.getCokeImp();
cokeImp.distributeCokeImp();
}
}
“这是小可乐：”
public class SmallCoke extends Coke
{
public SmallCoke() {}
public void distributeCoke()
{
System.out.print("SmallCoke ");
CokeImp cokeImp = this.getCokeImp();
cokeImp.distributeCokeImp();
}
}
“我要加冰：”
public class IceCokeImp extends CokeImp
{
IceCokeImp() {}
public void distributeCokeImp()
{
System.out.print("Ice added");
}
}
“不要冰了：”
public class NonIceCokeImp extends CokeImp {
NonIceCokeImp() {}
public void distributeCokeImp()
{
System.out.print("Havn't ice");
}
}
“这里需要注意了，由于我们的CokeImp和Coke是一对一的关系，所以要从我们的用例中找到这个*Imp是一个比较关键和困难的事情。”
“好啦，现在，你想喝哪种可乐？”
“我要小杯可乐加冰！”“这个简单，给你……”
Coke coke = new SmallCoke();
coke.setCokeImp(new IceCokeImp());
coke.distributeCoke();
“我要大杯可乐不加冰！”“Oh，Here！”
Coke coke = new BigCoke();
coke.setCokeImp(new NonIceCokeImp());
coke.distributeCoke();
“差不多Bridge模式就讲完了，另外，Bridge被广泛的应用于GUI和其它图形图象应用程序种，包括Java AWT。另外，Abstract Factory（抽象工厂模式）经常用来创建和设定一个Bridge，Bridge模式类似于Adapter（适配器模式）中的对象适配器模式。上面的两个模式上次不是都对你讲过了嘛。”
“哦，你一说我到想起来了，”Helen咬着手指，非常可爱的模样。“哇，迷死人了！”AndyTao 只有偷偷想的份。^_^
“不过，你还要注意了，你在设计Bridge类的时候，要注意对一个抽象的实现部分的修改应对客户不产生影响，即客户的代码不必重新编译。另外，Bridge将会有许多类要生成，这样一种
类层次结构说明你必须将一个对象分解成两个部分，抽象部分和实现部分。总之一句话，将抽象部分与它的实现部分分离，使它们都可以独立地变化。这就是Bridge模式的精髓所在了，还有……”
“还有什么，跟个唐僧似的。”“还有啊，别忘了你的可乐！哈哈哈！！”
“你呀，什么都记不住，就这在行。”
“哇，你这么了解我啊。”“去死吧你……”“哈哈哈！！！”
前言：看着csdn渐渐让人失望，本来打算不写了。可是老师们教我善始善终，呵呵，那就坚持一回吧。
概念：
Builder：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
---------------------------------------------------------------------------------------
“嘿，Andy，来帮帮忙，帮我装装机子吧。”，Helen又在那喳喳呼呼了。
“好的，好的，喔……，新机诶！”，走过去一看，AndyTao眼一亮。唉，看到人家的新配置，他就有一种据为己有的冲动。说实在的，咱玩电脑的，没几个不这山望着那山高的。。。
“这么大个丫头，到现在还是不会装机器。你怎么学的啊？”AndyTao嘴上这么说，心里想，“最好永远学不会！”
“好的，好的，谢谢你嘛！不过，如果能把你的脑子也装过来就好了。”
“嘿，不是吧，要求过分。。。。。。这样吧，嗯，顺便给你说说设计模式吧！”
“这装机也是个设计模式？”
“听下去！”
“哦。。。”，Helen噘嘴的样子真TMD可爱，AndyTao不觉想入非非了。
“我就给你说说设计模式里的Builder模式好了。Builder模式是一步一步创建一个复杂的对象，它允许用户可以只通过指定复杂对象的类型和内容就可以构建它们。用户不知道内部的具体构建细节。”
“诶，这个和抽象工厂模式不是很相似么？”
“Builder模式是非常类似抽象工厂模式,细微的区别大概只有在反复使用中才能体会到。待会我讲讲Builder和Abstract Factory模式之间的一些区别好了。”
“它一般用在下面两种情况下：
1、当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。
2、当构造过程必须允许被构造的对象有不同的表示时。
上面的说法太抽象。简单点来说，它是为了将构建复杂对象的过程和它的部件解耦，从而达到将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。”
“不懂……具体的来说呢？”
“因为一个复杂的对象，有大量组成部分，有时候多得让人头晕，就拿PC机来说吧：PC机有很多部件：
主板，CPU，硬盘，显示器……还有各种小零件，配件等等；部件很多，如何将这些部件装配成一台PC？
这个装配过程也很复杂，需要很好的组装技术(还吓不着你？)，那么我们为了更好的组织PC机这个大对象，就需要一种相应的方法来进行装配。我们要说的Builder模式也就是为了将部件和组装过程分开而产生的。”
“不明白……”
“唉，笨笨，拿你没办法……”
“这样吧，我们说说具体怎么使用先！”
“首先假设一个复杂对象是由多个部件组成的，Builder模式是把复杂对象的创建和部件的创建分别开来，分别用Builder类和Director类来表示。”
“首先,需要一个接口,它定义如何创建复杂对象的各个部件:
public interface Builder {
//创建部件A 比如生产主板
void buildPartA();
//创建部件B 比如生产CPU
void buildPartB();
//创建部件C 比如生产硬盘
void buildPartC();
……
//返回最后组装成品结果 (返回最后装配好的PC)
//成品的组装过程不在这里进行，而是转移到下面的Director类中进行。
//从而实现了过程和部件的分离
Product getProduct();
}
用Director构建最后的复杂对象,而在上面Builder接口中封装的是如何创建一个个部件(复杂对象是由这
些部件组成的),也就是说Director的内容是如何将部件最后组装成成品:
public class Director {
private Builder builder;
public Director( Builder builder ) {
this.builder = builder;
}
// 将部件partA partB partC最后组成复杂对象
//这里是将主板、CPU和硬盘组装成PC的过程
public void construct() {
builder.buildPartA();
builder.buildPartB();
builder.buildPartC();
}
}
Builder的具体实现ConcreteBuilder:
通过具体完成接口Builder来构建或装配产品的部件; 定义并明确它所要创建的是什么具体东西;
提供一个可以重新获取产品的接口:
public class ConcreteBuilder implements Builder {
Part partA, partB, partC;
public void buildPartA() {
//这里是具体如何构建partA的代码
};
public void buildPartB() {
//这里是具体如何构建partB的代码
};
public void buildPartC() {
//这里是具体如何构建partB的代码
};
public Product getProduct() {
//返回最后组装成品结果
};
}
复杂对象：产品Product：
public interface Product { }
复杂对象的部件：
public interface Part { }
我们看看如何调用Builder模式：
ConcreteBuilder builder = new ConcreteBuilder();
Director director = new Director( builder );
director.construct();
Product product = builder.getProduct(); ”
“上面所讲的就是Builder模式的一般性使用方法了。至于Builder和Abstract Factory模式的区别，Builder强调的是整体是由部分组成的这个概念，比如你想要得到PC这个复杂对象，那你一定要先准备好主板，CPU，硬盘等等这些构造PC所必须的简单对象，之后调用Builder
的get操作得到PC这个最终产品；
而Abstract Factory模式则并不强调这种关系，或者可以说是构造上的‘松耦合’。”
“嗯，咱们来个形象点的比喻吧：Builder模式是用来制造产品的，你的角色相当于产品制造商，知道怎么用部件来制造产品，而部件来自部件制造商，你可以利用不同种类的部件，也可以用同种类的部件采用不同的制造方法。而Abstract Factory是从用户角度来考虑的，主要是给用户提供产品系列，用户可以方便的使用这些产品系列，但是用户没有可能去改变产品，只能使用已有的产品系列。
例如：Builder模式适用于计算机发烧友，经常DIY的；而Abstract Factory模式适用于喜欢稳定的品牌机，像IBM，联想之类的。”
“你的意思是不是，constructor依次调用Builder的buildPart方法，全部完成后再调用getProduct方法得到整个product？那为什么不在Builder中加一个construct方法，依次调用
自己的buildPart方法呢？这样还可以减少constructor和Builder之间的耦合。或者说，这种调用是运行时确定的，所以无法写在Builder中间吗？”
“还是上面所说的，如果将构造过程放在Builder里来作，那就失去的构造的灵活性。还拿PC 来说吧，如果你在Builder里构造一种PC，80G硬盘的；但是你又想构造另外一种PC，100G硬盘的；你绝对不愿意再修改你的Builder吧，所以Builder用来构造Part，而整体的结构就由另外的一个Director来得到。简单点来说，就是由你自己去组合这些零件，最后调用get方法得到你要的product。”
“在Java实际使用中，我们经常用到‘池’(Pool)的概念,当资源提供者无法提供足够的资源,并且这些资源需要被很多用户反复共享时,就需要使用池了。‘池’实际是一段内存，当池中有一些复杂的资源的‘残余’(比如数据库的连接池，也许有时一个连接会中断)，如果循环再利用这些‘残余’，将提高内存使用效率，提高池的性能。重在组装！”
“哦也，我有点明白了……你真行啊！”
“哪里哪里！！！”
“你以为我夸你哪？？？我说你弄半天还没有帮我把机子装好，你真行啊！！！”
“我晕……倒！你个小妮子！”
软件设计师23种设计模式总结
创建型结构型行为型 类Factory Method Adapter In terpreter Template Method 对象 Abstract Factory Builder Prototype Si ngleto n Apapter(对象) Bridge Composite Decorator Fa?ade Flyweight Proxy Chain of Resp on sibility Comma nd Iterator Mediator Meme nto Observer State Strategy Visitor （抽象工厂） 提供一个创建一系列相关或互相依赖对象的接口，而无须制定它们具体的类。 图10-25抽象工厂模式结构图 Abstract Factory 抽象工厂 class Program { static void Main(string[] args) { AbstractFactory factory1 = new Con creteFactory1(); Clie nt c1 = new Clie nt(factory1); c1.Ru n(); AbstractFactory factory2 = new Con creteFactory2(); Clie nt c2 = new Clie nt(factory2); c2.Ru n(); Co nsole.Read(); abstract class AbstractFactory { public abstract AbstractProductA CreateProductA(); public abstract AbstractProductB
设计模式心得体会
设计模式心得体会 7月初的一个周末，准确的说应该是7月1号周六，在网上看到一本《大话设计模式》的书，而且看到很多很好的评论，于是乎，下载了电子书看看，一下子看了几章之后，对设计模式有了个了解，于是继续上网搜些其他资料，进一步了解设计模式。。。最终结论：设计模式是个好东西，具体怎么好，一两句话是无法概括的，也是从那天起，我就决定学习设计模式，于是就看《大话设计模式》，至七月十多号，大概看了一百多页后，感觉有点难，有点看不下去的感觉，于是上网找其他的好方法，无意间发现了李建忠老师的《c#设计模式纵横谈》系列讲座，微软的web cast课程，主要讲解gof的23个设计模式，每个一讲，加上一头一尾，共25讲，试听了一节课后，感觉很有用，于是就抽时间去边听课边看书，并在我的博客里写下笔记，依赖加深印象，二来可以督促我的进度。。。 三个月以来，总算把设计模式学完一遍了，原计划是两个月学完（一星期三个模式），由于。。。计划两个月学完实际花了三个月，感触多多，收获多多——对c#语言有了更进一步的认识，对oo的思想有了更全面的了解。。。 下一步在设计模式方面的计划：巩固并运用设计模式，巩固：把《大话设计模式》，《设计模式》，《设计模式——可
复用的面向对象基础》，《敏捷软件开发：原则、模式与实践》这些书再结合起来系统的看一看，当然还会去买一些我手头上没有的关于设计模式的书；运用：部门前几天也提倡用c#来改版vb程序，我想这是一个很好的平台，正好有机会把理论的东西在实际中应用，理论加实际——唯一的学习方法。。。 下面对各个模式再简单总结一下： 1、创建型模式： singleton：解决的是实例化对象的个数的问题，比如抽象工厂中的工厂、对象池等，除了singleton之外，其他创建型模式解决的都是 new 所带来的耦合关系。 abstract factory：创建一系列相互依赖对象，并能在运行时改变系列。 factory method：创建单个对象，在abstract factory 有使用到。 prototype：通过拷贝原型来创建新的对象。 factory method，abstract factory, builder都需要一个额外的工厂类来负责实例化“一边对象”，而prototype 则是通过原型（一个特殊的工厂类）来克隆“易变对象”。 如果遇到“易变类”，起初的设计通常从factory method 开始，当遇到更多的复杂变化时，再考虑重构为其他三种工
设计模式优缺点及应用场景整理
看完发现有不太对的地方告诉我下 各设计模式优缺点总结 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.通过将控制逻辑集中，可以简化系统维护
Java设计模式学习心得
Java设计模式之心得 UML 1.案例图:系统角色和使用案例和它们之间的关系 2.类图: 类图中的关系 1.一般化关系：继承,接口 2.关联关系：类与类之间的联系Driver中的Car 3.聚合关系：整体与个体之间的关系 4.合成关系：强关联，整体包含部分，整体代表部分的生命周期，不能共享 5.依赖关系：类与类之间的连接，如Person包含Car和House 3.时序图： 每个步骤的流程图 4.状态图：一系列对象的内部状态及状态变化和转移 5.合作图：相互关系图 6.构建图：部署的软件构件之间的关系 7.活动图： 8.部署图： 面向对象的设计原则： 1.设计目标：可扩展性、可维护性、可插入性、可复用性 2.设计原则：开闭原则、里氏替换原则、依赖倒转原则、接口隔离原则、组合\聚合复用原则、迪米特法则 开闭原则：
OCP作为OO的高层原则，主张使用“抽象(Abstraction)”和“多态(Polymorphism)”将设计中的静态结构改为动态结构，维持设计的封闭性。 一句话：“Closed for Modification;Open for Extension”——“对变更关闭；对扩展开放”。开闭原则其实没什么好讲的，我将其归结为一个高层次的设计总则。OCP的动机很简单：软件是变化的。不论是优质的设计还是低劣的设计都无法回避这一问题。OCP说明了软件设计应该尽可能地使架构稳定而又容易满足不同的需求。 重要的步骤： 1.抽象化 2.对可变性的封装原则 里氏替换原则： 1.分析对象时必须明确是Is-a还是Has-a的关系,任何基类适应的地方，子类一定适用依赖倒转原则： 要依赖于抽象，不要依赖于具体。简单的说，依赖倒置原则要求客户端依赖于抽象耦合。原则表述：抽象不应当依赖于细节；细节应当依赖于抽象；要针对接口编程，不针对实现编程。 接口隔离原则： 使用多个专门的接口比使用单一的总接口要好。广义的接口：一个接口相当于剧本中的一种角色，而此角色在一个舞台上由哪一个演员来演则相当于接口的实现。因此一个接口应当简单的代表一个角色，而不是一个角色。，如果系统设计多个角色的话，则应当每一个角色都由一个特定的接口代表。狭义的接口（Interface）:接口隔离原则讲的就是同一个角色提供宽、窄不同的接口，以对付不同的客户端。 组合\聚合复用原则： 要尽量使用组合/聚合，而不是使用继承来达到目的 原因： 继承复用的缺点：静态复用 什么使用使用继承：a.满足is-a的关系，而不是has-a的关系 b.满足lsp原则 优点：a.简洁 b.父类修改某个方法，子类能获得 迪米特法则： 一个对象或模块应该和其它对象和模块尽量少的通信（高内聚），涉及的模式有：门面模式，调停者模式，前端控制器模式，业务代表模式，dao模式
设计模式总结 通过命令模式
注： 文档内容基本上来自于网上，并加上自己的理解而成。有的觉得网友总结得非常好，就完全照搬下来，供学习之用。然而，有的摘抄并没有加上原链接和出处，请谅解。 通过命令模式，通过在客户端和具体的命令之间添加一层Invoker，剪断了客户端和具体服务提供者之间的耦合，降低了两者之间的耦合度，同时也增加了灵活性，比如我们可以灵活的某一个请求的服务提供者，通过单独的服务提供者Command类，可以很方便的提供redo和undo的功能等等，这些都是命令模式的优势。 在软件系统中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合，比如要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，实现二者之间的松耦合。这就是命令模式（Command Pattern） 即命令模式的核心是要解决“行为请求者”和“行为实现”都之间的耦合，以达到灵活多变的效果。 目标： 客户只需要发命令，而不需要管命令是如何被执行的！Command pattern From Wikipedia,the free encyclopedia In object-oriented programming,the command pattern is the method and values for the method parameters.
?
? ? ? ? ? ? ? ? ? ? [edit]Uses
[edit]Structure
UPDATE:The explanation for the Receiver block above should be "The actual work to be done by the command(action)" [edit]Terminology 1.Ambiguity. 2.The term command is ambiguous.For example,move up,move up may refer to a single
23种设计模式趣味讲解
23种设计模式趣味讲解 对设计模式很有意思的诠释，呵呵，原作者不详。 创立型模式 1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，固然口味有所不同，但不管你带MM往麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory 工厂模式：客户类和工厂类离开。花费者任何时候需要某种产品，只需向工厂恳求即可。花费者无须修正就可以接纳新产品。毛病是当产品修正时，工厂类也要做相应的修正。如：如何创立及如何向客户端供给。 2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同处所的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM 我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你”builder。（这必定比美军在伊拉克用的翻译机好卖） 建造模式：将产品的内部表象和产品的天生过程分割开来，从而使一个建造过程天生具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变更，客户不必知道产品内部组成的细节。建造模式可以强迫履行一种分步骤进行的建造过程。 3、FACTORY METHOD—请MM往麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。 工厂方法模式：核心工厂类不再负责所有产品的创立，而是将具体创立的工作交给子类往做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的串口，而不接触哪一个产品类应当被实例化这种细节。 4、PROTOTYPE—跟MM用QQ聊天，必定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里面就行了，这就是我的情话prototype了。（100块钱一份，你要不要） 原始模型模式：通过给出一个原型对象来指明所要创立的对象的类型，然后用复制这个原型对象的方法创立出更多同类型的对象。原始模型模式容许动态的增加或减少产品类，产品类不需要非得有任何事先断定的等级结构，原始模型模式实用于任何的等级结构。毛病是每一个类都必须配备一个克隆方法。 5、SINGLETON—俺有6个美丽的老婆，她们的老公都是我，我就是我们家里的老公Sigleton，
设计模式报告
课程名称设计模式课程设计 设计题目设计模式在FileUpload 组件中的应用 班号专业软件工程 学生姓名 ###### 指导教师（签字） 课程设计说明书
目录 第一章设计模式概述 1.1模式与设计模式 1.2设计模式的定义 1.3设计模式的基本要素 1.4设计模式的分类 第二章FileUpload组件简介 2.1FileUpload组件由来及使用 2.2 FileUpload组件的工作原理 2.3 FileUpload组件中的部分接口、类简介 第三章设计模式在FileUpload组件中的应用 3.1 工厂方法模式在FileUpload组件中的应用 3.2 策略模式在FileUpload组建中的应用 3.3 迭代器模式在FileUpload组建中的应用 3.4 FileUpload组件中的重要类图 第四章结束语 4.1 收获与总结 4.2 参考文献 第一章设计模式概述
1.1模式与设计模式 模式起源于建筑业而非软件业，模式(Pattern)之父—美国加利佛尼亚大学环境结构中心研究所所长Christopher Alexander博士。Alexander给出了关于模式的经典定义:每个模式都描述了我们环境中不断出现的问题，然后描述了解决这个问题解决方案的核心，通过这种方式，我们可以无数次的重用那些已有的解决方案，无需再重复相同的工作，也可以用一句话概括为：模式是在特定环境中解决问题的一种方案。 最早将Alexander博士的模式思想引入软件工程方法学的是以四人组（Gang of Four,GoF）自称的四位著名软件工程学者，他们在1949归纳发表的23中在软件开发中使用频率较高的设计模式，旨在用模式来统一沟通面向对象方法学在分析、设计和实现间的鸿沟。 GoF将模式的概念引入软件工程领域，标志着软件模式的诞生，软件模式是将模式的一般概念应用于软件开发领域，即软件开发的总体指导思想或参照样板软件模式并非仅限于设计模式，还包括架构模式、分析模式、和过程模式等。 从1987年Kent Beck和Ward Cunningham借鉴Alexander的模式思想在程序开发中开始应用一些模式到目前设计模式在软件开发的广泛应用,Sun公司的Java SE/Java EE平台和Microsoft公司的.net平台设计中就应用了大量的设计模式。再设计模式领域，下一的设计模式是指GoF的《设计模式：可复用面向对象软件的基础》一书中包含的23中经典设计模式，不过设计模式并不仅仅只有这23中，随着软件开发技术的发展，越来越多的模式不断诞生并得以广泛应用。 1.2设计模式的定义 设计模式（Design Pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码，让代码更容易被他人理解，保证代码的可靠性。 1.3设计模式的基本要素 1.3.1模式名称(Pattern name)
Gof的23种设计模式
Gof的23种设计模式 从2005年初听说设计模式，到现在虽然已经8年多了，但GoF的23种模式依然盛行，当然GoF提出这些模式的 年代更加久远（1995年）。在工作的过程中，陆陆续续接触了GoF的大部分模式，我记得在2008年的时候就想总结一下设计模式（最近想做的两件事情），最后因为各种原 因也没有完成。最近这段时间正好是职业空档期，没什么事儿做，就把之前看过的设计模式翻出来整理了一下，于是就有了上面几篇文章。整理设计模式的过程，也是一个深刻理解面向对象设计的过程。通过对各个模式的回顾，让我更能够明白前辈们关于面向对象设计提出的各种“最佳实践”，特别是S.O.L.I.D，我觉得在这里再说一次，也不算矫情。S：单一职责原则（Single Responsibility Principle, SRP），一个类只能有一个原因使其发生改变，即一个类只承担一个职责。 O：开放-封闭原则（Open-Close Principle, OCP），这里指我们的设计应该针对扩展开放，针对修改关闭，即尽量以扩展的方式来维护系统。 L：里氏替换原则（Liskov Subsititution Principle, LSP），它表示我们可以在代码中使用任意子类来替代父类并且程 序不受影响，这样可以保证我们使用“继承”并没有破坏父类。
I：接口隔离原则（Interface Segregation Principle, ISP），客户端不应该依赖于它不需要的接口，两个类之间的依赖应该建立在最小接口的基础上。这条原则的目的是为了让那些使用相同接口的类只需要实现特定必要的一组方法，而不是大量没用的方法。 D：依赖倒置原则（Dependence Inversion Principle, DIP），高层模块不应该依赖于低层模块，两者应该都依赖于抽象；抽象不依赖于细节，而细节应该依赖于抽象。这里主要是提倡“面向接口”编程，而非“面向实现”编程。设计模式，从本质上讲，是针对过去某种经验的总结。每种设计模式，都是为了在特定条件下去解决特定问题，离开这些前提去讨论设计模式，是没有意义的。下面，我们快速回顾GoF的23种模式。工厂方法 意图：定义一个用户创建对象的接口，让子类去决定具体使用哪个类。 适用场合：1）类不知道它所要创建的对象的类信息；2）类希望由它的子类来创建对象。抽象工厂 意图：提供一个创建一系列相关或者相互依赖的对象的接口，而无须指定它的具体实现类。 适用场合：1）系统不依赖于产品是如何实现的细节；2）系统的产品族大于1，而在运行时刻只需要某一种产品族；3）属于同一个产品族的产品，必须绑在一起使用；4）所有的
模式总结
设计模式总结 一、创建型模式 简单工厂 简单工厂最大优点在于工厂类中包含了必要的逻辑判断（switch），根据客户端的选择条件动态实例化相关的类，对于客户端来说，去除了与具体产品的依赖。 工厂方法 工厂方法模式（Factory Method），定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。 工厂方法模式实现时，客户端要觉定实例化哪一个工厂来实现运算类，选择判断的问题还是存在的，也就是说，工厂方法把简单工厂的内部逻辑判断移到了客户端代码来进行。你想要加功能，本来是改工厂类的，而现在时修改客户端。 抽象工厂 抽象工程模式（Abstract Factory），提供一个创建一系列相关或相互依赖对象的接口，而无需制定它们具体的类。 原型模式 原型模式（Prototype）,用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。 原型模式其实就是从一个对象再创建另外一个可定制的对象，而且不需要知道任何创建的细节。（拷贝对象的引用地址《浅表副本》）。.NET在System命名空间中提供了ICloneable接口（里面唯一的方法Clone()）,只要实现这个接口就可以完成原型模式。 建造者模式 建造者模式（Builder）,将一个复杂对象的构造过程与它的表示分离，使得同样的构造过程可以创建不同的表示。
如果使用建造者模式，那么用户就只需建造的类型就可以得到它们，而具体建造的过程和细节就不需要知道了。——抽象不应该依赖细节，细节应该依赖于抽象。建造者模式主要用于创建一些复杂的对象，这些对象内部构建间的建造顺序通常是稳定的，但对象内部的构建通常面临着复杂的变化。 单例模式 单例模式（Singleton），保证一个类仅有一个实例，并提供一个访问它的全局访问点。 二、行为型模式 观察者模式 观察者模式（Observer），定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生改变时，会通知所有观察者对象，使它们能自动更新自己。 当一个对象的改变需要同时改变其他对象的时候，而且他不知道具体有多少对象有待改变，应该考虑使用观察者模式。观察者模式所做的工作其实就是在解除耦合，让耦合的双方都依赖于抽象，而不依赖于具体，从而使得各自的变化都不会影响另一边的变化。 模板方法模式 模板方法模式（TemplateMethod），定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构可重复定义该算法的某些特定的步骤。 模板方法模式是通过把不变行为搬移到超类，去除子类中德重复代码来体现它的优势。模板方法模式就是提供了一个很好的代码复用平台。 状态模式 状态模式（State），当一个对象的内在状态发生改变时允许改变其行为，这个对象看起来像是改变了其类。
设计模式复习提纲
设计模式复习提纲 第一章 1.状态图的定义 状态图用来描述一个特定对象的所有可能状态及其引起状态转移的事件。 第二章 1.软件的可维护性和可复用性（？） 软件可维护性，即维护人员对该软件进行维护的难易程度,具体包括理解、改正、改动和改进该软件的难易程度。 可复用性：复用又叫重用，是重复使用的意思。 2.面向对象设计原则 （1）单一职责原则 （2）开闭原则 （3）里氏代换原则 （4）依赖倒转原则 （5）接口隔离原则 （6）合成复用原则 （7）迪米特法则 3.单一职责原则定义 单一职责原则定义：一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。 另一种定义：就一个类而言，应该仅有一个引起它变化的原因。 4.开闭原则定义 开闭原则定义：一个软件实体应当对扩展开放，对修改关闭。 5.里氏代换原则定义 里氏代换原则有两种定义方式。 第一种定义方式相对严格，其定义如下： 如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P 在所有的对象o1都代换成o2时，程序P的行为没有变化，那么类型S是类型T的子类型。第二种更容易理解的定义方式如下： 所有引用基类（父类）的地方必须能透明地使用其子类的对象。 6.依赖倒转原则定义 依赖倒转原则定义：高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。 另一种表述为：要针对接口编程，不要针对实现编程。 7.接口隔离原则定义 接口隔离原则定义：客户端不应该依赖那些它不需要的接口。注意：在该定义中的接口指的是所定义的方法。
另一种定义方法：一旦一个接口太大，则需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。 8.合成复用原则定义 合成复用原则，又称为组合/聚合复用原则，其定义如下：尽量使用对象组合，而不是继承来达到复用的目的。 9.迪米特法则定义 迪米特法则，又称为最少知识原则，它有多种定义方法，其中几种典型定义如下： (1)不要和“陌生人”说话。 (2)只与你的直接朋友通信。 (3)每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。 第三章 1.模式的定义 每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心，通过这种方式，我们可以无数次地重用那些已有的解决方案，无需再重复相同的工作。可以用一句话简单表示为：模式是在特定环境中解决问题的一种方案。 2.设计模式的定义 设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 3.设计模式的基本要素 设计模式一般有如下几个基本要素：模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式，其中的关键元素包括以下四个方面：模式名称、问题、解决方案、效果。 4.设计模式的分类 （1）根据其目的（模式是用来做什么的）可分为创建型、结构型和行为型三种： ①创建型模式主要用于创建对象。 ②结构型模式主要用于处理类或对象的组合。 ③行为型模式主要用于描述对类或对象怎样交互和怎样分配职责。 （2）根据范围，即模式主要是用于处理类之间关系还是处理对象之间的关系，可分为类模式和对象模式两种： ①类模式处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，是属于静态的。 ②对象模式处理对象间的关系，这些关系在运行时刻变化，更具动态性。 5.GoF设计模式简介 GoF 最先将模式的概念引入软件工程领域，他们归纳发表了23种在软件开发中使用频率较高的设计模式，旨在用模式来统一沟通面向对象方法在分析、设计和实现间的鸿沟。
设计模式学习总结
设计模式学习总结 引子 刚开始学习设计模式的时候.感到这些模式真的非常抽象。今年下半年以来.随着我们组工作重点的转移.以及我在小组中角色的变化.我开始有条件提出自己对新系统的设计想法。在设计过程中.我发现了很多设计模式的用处.也确实应用了很多设计模式.这让我越来越感到设计模式的重要性.因此我写了这十余篇专门介绍设计模式的文章.作为我的学习笔记。 《设计模式——可复用的面向对象软件的基础》（有趣的是.梅宏一再在组会上强调应该译成重用）中介绍了一共23种设计模式.我一共写了19个设计模式（其中三个和在一篇文章中）.余下四个.考虑到该模式的应用范围我就没有介绍。在写这些文章时.其中的很多例子都是我在实践中提炼出来的.当然也有很大一部分是《设计模式》中的例子。不过.这四个人（四人团）生活的年代里现在已经很远了.所以它们的例子也很古老。 让我们更加设计模式 设计模式是个好东西.它给出了很多设计中的技巧与思路.对于很多优秀的设计.它加以总结与提炼。设计模式并非四人团拍脑瓜想出来的.而是他们搜集了其他人优秀的设计.加以整理出来的.他们不是这些模式的创造者.仅仅是整理者。 应用设计模式会给我们带来很多好处：软件将变得更加灵活.模块之间的耦合度将会降低.效率会提升.开销会减少。更重要的.设计模式就好像美声唱法中的花腔.让你的设计更加漂亮。总的来说.设计模式似乎将软件设计提升到艺术的层次。 设计模式已经被广泛的应用了.在现在很多的图形界面框架都使用了MVC模式.大量跌代器模式的应用.彻底改变了我们对集合的操作方式。不仅如此.应用了设计模式的设计.往往被看成为优秀的设计。这是因为.这些设计模式都是久经考验的。 模式不是模型 在学习和使用设计模式的时候.往往出现一个非常严重的误区.那就是设计模式必须严格地遵守.不能修改。但是设计模式不是设计模型.并非一成不变。正相反.设计模式中最核心的要素并非设计的结构.而是设计的思想。只有掌握住设计模式的核心思想.才能正确、灵活的应用设计模式.否则再怎么使用设计模式.也不过是生搬硬套。
设计模式及优点总结
桥接模式——Bridge 将抽象部分与它的实现部分分离，使它们都可以独立地变化。 什么叫抽象与它的实现分离，这并不是说，让抽象类与其派生类分离，因为这没有任何 意义。实现指的是抽象类和它的派生类用来实现自己的对象。由于实现的方式有多种，桥接模式的核心意图就是把这些实现独立出来，让它们独自地变化。这就使得每种实现的变化不会影响其他实现，从而达到应对变化的目的。 桥接模式的结构图如下： 将抽象部分与它的实现部分分离，这不是很好理解，我的理解就是实现系统可能有很多角度分类，每一种分类都有可能变化，那么就把这种多角度分离出来让它们独立变化，减少它们之间的耦合。也就是说，在发现我们需要多角度去分类实现对象，而只用继承会造成大量的类增加，不能满足开放—封闭原则时，就应该要考虑桥接模式。 单例模式——Singleton 单例模式，保证一个类仅有一个实例，并提供一个访问它的全局访问点。 通常我们可以让一个全局变量使得一个对象被访问，但它不能防止你实例化多个对象，一个最好的办法就是，让类自身负责保存它的唯一实例。这个类可以保证没有其他实例可以被创建，并且他可以提供一个访问该实例的方法。 单例模式的结构图如下：
单例模式因为Singletion类封装它的唯一实例，这样它可以严格控制客户怎样访问它以及何时访问它。简单地说就是对唯一实例的受控访问。 当在多线程情景下使用时，需要对GetInstance全局访问点加锁。适配器模式(Adapter) 将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼 容而不能一起工作的哪些类可以一起工作。 也就是说系统的数据和行为都是正确的但接口不符时，我们应该考虑用适配器模式，目的是使控制范围之外的一个原有对象与某个接口匹配。适配器模式主要应用于希望复用一些现存的类，但是接口又与复用环境要求不一致的情况，比如说需要对早期代码复用一些功能等应用上很有实际价值。 适配器又两种类型，类适配器模式和对象适配器模式。但由于类适配器通常是通过多重继承实现的，而C#、https://www.wendangku.net/doc/7714178286.html,、JAVA等语言都不支持多重继承，也就是一个类只有一个父类，所以，我们这里主要讲对象适配器。 适配器模式的结构图如下：
23种设计模式_UML_类图及对应示例代码
23种设计模式UML 类图及对应示例代码(一) 收藏 1.DoFactory.GangOfFour.Abstract.Structural Abstract Factory：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。 工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。 using System; namespace DoFactory.GangOfFour.Abstract.Structural { ///
class MainApp { ///
设计模式学习总结(一)
前言： 推荐几本相关的书： （1）Head First Design Patterns 曾经买Head First系列的时候买的一本书，是java语言的案例，但是完全不影响你了解设计模式。这系列的书就是有很多图，做快速了解建议买。 （2）大话设计模式 1个月前买的，看作者简介是名老师，里面就是菜鸟和大鸟的对话举出很多例子，案例也相当不错。这本书最起码让我感觉特别不错。 （3）重构与模式 这本是必须要看的一本书，前几张讲了什么是重构，什么是模式。然后两者之间的关系。后边是是讲设计模式的动机，做法，实例，变体。也不分什么创建，行为，结构什么的。最后一章是重构的实现。 一．设计原则 单一职责原则告诉我们实现类要职责单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。而开闭原则是总纲，他告诉我们要对扩展开放，对修改关闭。 1.开闭原则OCP(Open-Close Principle) 【开指的是对扩展开放，关指的对修改关闭。】 我把它理解为“一国两制”原则。一国两制怎么说：香港澳门继承了中国这个类，表示说：一个中国不可改变，但针对与港澳实际情况，他们实行的是资本主义经济。 2.单一职责原则RRP（Single Responsibility Principle） 【一个类应该只有一个发生变化的原因。】 高内聚低耦合这就是我们写程序的目标，但是很多时候高耦合会在不经意间就产生了，这大多是因为职责扩散造成的。这个原则最好理解，又最容易违背这个原则。原因就是职责这个家伙不好确认。
Java23种设计模式6大原则总结
设计模式概念：一套被反复使用、多数人知晓、经过分类编目的优秀代码设计经验的总结。设计模式要素：模式名称、问题、举例、末态环境、推理、其他有关模式、已知的应用。设计模式分类：创建型、结构型、行为型。 创建型模式功能：1.统所使用的具体类的信息封装起来； 2.类的实例是如何被创建和组织的。 创建型模式作用：1.封装创建逻辑，不仅仅是new一个对象那么简单。 2.封装创建逻辑变化，客户代码尽量不修改，或尽量少修改。 常见的创建型模式：单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式。常见的结构型模式：代理模式、装饰模式、适配器模式、组合模式、桥梁模式、外观模式、享元模式。 常见行为型模式：模板方法模式、命令模式、责任链模式、策略模式、迭代器模式、中介者模式、观察者模式、备忘录模式、访问者模式、状态模式、解释器模式。单一职责原则：一个类应该只有一个职责。 优点：降低类的复杂性；提高类的可读性；提高代码的可维护性和复用性；降低因变更引起的风险。 里氏替换原则： 优点：代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；提高代码的可重用性；提高代码的可扩展性；提高产品或项目的开放性。 缺点：1.继承是入侵式的。只要继承，就必须拥有父类所有属性和方法。 2.降低代码的灵活性。子类必须拥有父类的属性和方法，使子类收到限制。 3.增强了耦合性。当父类的常量、变量和方法修改时，必须考虑子类的修改，这种 修改可能造成大片的代码需要重构。 依赖倒置原则：高层模块不应该依赖低层模块，两者都依赖其抽象；抽象不依赖细节；细节应该依赖于抽象。 在Java中的表现：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；接口或抽象类不依赖于是实现类； 实现类依赖于接口或抽象类。 接口隔离原则：1.一个类对另外一个类的依赖性应当是建立在最小的接口上的 2.一个接口代表一个角色，不应当将不同的角色交给一个接口。 3.不应该强迫客户使用它们的不同方法。 如图所示的电子商务系统在三个地方会使用到订单类：一个是门户，只能有查询方法；一个是外部系统，有添加订单的方法；一个是管理后台，添加、删除、修改、查询都要用到。“原子”在实践中的衡量规则： 1.一个接口只对一个子模块或者业务逻辑进行分类。 2.只保留接口中业务逻辑需要的public方法。 3.尽量修改污染了的接口，若修改的风险较大，则可采用适配器模式进行转化处理。 4.接口设计应因项目而异，因环境而异，不能照搬教条。 迪米特法则：（表述）只与你直接的朋友们通信；不要跟“陌生人”说话；每一个软件单位 对其他的单位都只有最少的了解，这些了解仅局限于那些与本单位密 切相关的软件单位。 对迪米特法则进行模式设计有两个：外观模式、中介者模式。 开闭原则：一个软件实体应当对扩展开放，对修改关闭。 重要性体现：提高复用性；提高维护性；提高灵活性；易于测试
设计模式课程设计
设计模式课程设计 题目：画图程序 学院：信息科学与技术学院 专业：软件工程 学号：20092384 姓名：陈志
1．需求分析 该系统是一个画图程序，我们要用设计模式的思想来设计系统结构，然后实现基本图形的绘制功能。 1.1 设计模式要求 至少在其中运用 6 种模式，其中涉及到的模式有装饰模式、策略模式、桥梁模式三种。 1.2 画图基本要求 能实现基本图形的绘制功能 1.3 画图高级要求 实现图形的操作（如选取、移动、放大、缩小、改变颜色、改变线形等）和持久化（利用文件或利用数据库）。 2.系统设计 首先，画图程序可以实现绘制圆形、矩形和按钮，这里可以将圆形、矩形和按钮看作三个不同的类，那么我们可以采用抽象工厂的方式来创建它们。对于画组合图，我们可以采用组合模式将二者结合起来。而对于图形颜色或者粗细的改变，我们可以使用外观模式。然后，我们可以使用原型模式来实现对于最后一个图形的复制。在系统中可以使用代理模式来实现显示图片。下面是对需要用到的设计模式进行的分析。 2.1 使用设计模式 2.1.1 桥梁模式 桥梁模式 , 结构型模式一种 .设计程序过程中 , 会经常使用到抽象类或者接口来完成抽象的过程。 继承或实现的类通过不同的实现方式来完成抽象类或接口的变化 , 也就是实现过程的变化 , 但可能会有这样的情况 , 抽象过程同样需要进行变化 , 也就是抽象类或者接口需要变化 , 这样就会造成原有的继承或实现关系复杂 , 关系混乱 .桥梁模式利用将抽象层和实现层进行解耦 , 使两者不再像继承或实现这样的较强的关系 , 从而使抽象和实现层更加独立的完成变化的过程 . 使系统更加清晰。 桥梁模式主要由抽象类、修正抽象类、实现类以及具体实现类组成 . 抽象类 , 制定接口 , 同时给出一个实现化的引用。 修正抽象类 , 扩展抽象类 , 修正或改变抽象类中指定的接口。 实现类 , 提供实现化角色的接口 , 但不进行具体实现过程 , 该接口不一定给出与抽象类相同的接口 , 只是提供实现的方式。 具体实现类 , 完成实现类中定义的实现接口的具体实现过程。 具体代码如下： package BridgePattern; import java.awt.Color;
项目回顾总结
项目回顾点总结
项目整合 下降 团队建设： 规范化的重要性。 对待恐惧和困难的态度，当战胜一个更大困难的时候的感觉，世界上没有战胜不了的困难只有在困难面前退缩的人。 工作的精细度。 器械的利用，KEEP THE BOX UNLOCKED。 营销团队： 执行力：无论从哪个层面来看，已经锁定了的目标，所依赖的关键执行力是中层经理人和销售队伍。因此必须把经历下放到中间层经理人和销售队伍上，让他们真正成为实现其发展战略的支柱，而不是配合者，更不是旁观者。执行力的力度在于专业化。一些企业缺乏的就是必要的专门人才在各个岗位上起到的专业打理的作用。还要注重整体效应 快鱼吃慢鱼：是思科CEO钱伯斯的名言，快鱼吃慢鱼强调了对市场机会和客户需求的客户反应，但决不是盲目扩张和仓促出击，正相反，真正的快鱼追求的不仅是快，更是准，因为只有准确地把握市场的脉搏，了解未来技术和服务的方向后，快速出击收购才是必要和有效的。而如何来挑选慢鱼，由市场决定，记住市场永远是正确的。有时候，太过精尖的技术不一定受到市场的欢迎。 文化营销：世界在消费麦当劳，其实是在消费美国快餐文化。作为优秀品牌，其在推广产品的同时，实质是在推广一种生活方式，推广一种文化。 团队营销：没有完美的个人，只有完美的团队。我们都是有缺陷的人，但是我们要成就一件完美的事业，只有靠配合。团队的产生是源于人性本身的不完善。某种意义上说，联想的成功是这个管理团队的成功，而不是一个人两个人的事情。我们首先要避免个人英雄主义，你一定要牢记：我们永远不能将个人利益，凌驾于整体利益以上，其次成员要注重个人目标的实现，队员之间是相对独立，又是协作与支持的关系。我们要善于区别对待，我们通过区别对待每一个人而建立一
八种架构设计模式及其优缺点
八种架构设计模式及其优缺点概述(上) 1. 什么是架构 我想这个问题，十个人回答得有十一个答案，因为另外的那一个是大家妥协的结果。哈哈，我理解，架构就是骨架，如下图所示： 人类的身体的支撑是主要由骨架来承担的，然后是其上的肌肉、神经、皮肤。架构对于软件的重要性不亚于骨架对人类身体的重要性。 2. 什么是设计模式
这个问题我问过的面试者不下于数十次，回答五花八门，在我看来，模式就是经验，设计模式就是设计经验，有了这些经验，我们就能在特定情况下使用特定的设计、组合设计，这样可以大大节省我们的设计时间，提高工作效率。 作为一个工作10年以上的老码农，经历的系统架构设计也算不少，接下来，我会把工作中用到的一些架构方面的设计模式分享给大家，望大家少走弯路。总体而言，共有八种，分别是： 1.单库单应用模式：最简单的，可能大家都见过 2.内容分发模式：目前用的比较多 3.查询分离模式：对于大并发的查询、业务 4.微服务模式：适用于复杂的业务模式的拆解 5.多级缓存模式：可以把缓存玩的很好 6.分库分表模式：解决单机数据库瓶颈 7.弹性伸缩模式：解决波峰波谷业务流量不均匀的方法之一 8.多机房模式：解决高可用、高性能的一种方法 3. 单库单应用模式这是最简单的一种设计模式，我们的大部分本科毕业设计、一些小的应用，基本上都是这种模式，这种模式的一般设计见下图：
如上图所示，这种模式一般只有一个数据库，一个业务应用层，一个后台管理系统，所有的业务都是用过业务层完成的，所有的数据也都是存储在一个数据库中的，好一点会有数据库的同步。虽然简单，但是也并不是一无是处。
优点：结构简单、开发速度快、实现简单，可用于产品的第一版等有原型验证需求、用户少的设计。 缺点：性能差、基本没有高可用、扩展性差，不适用于大规模部署、应用等生产环境。 4. 内容分发模式基本上所有的大型的网站都有或多或少的采用这一种设计模式，常见的应用场景是使用CDN技术把网页、图片、CSS、JS等这些静态资源分发到离用户最近的服务器。这种模式的一般设计见下图：