设计模式

生成器模式（Builder Pattern）是一种设计模式，又名：建造模式，是一种对象构建模式。它可以将复杂对象的建造过程抽象出来（抽象类别），是这个抽象过程的不同实现方法可以构造出不同表现（属性）的对象。（维基百科）

建造者模式也叫作生成器模式。建造者模式是一种创建型模式。 概念中说这种设计模式可以将复杂对象的构建过程抽象出来。也就是说共同特点的一类产品，我们将他们的构造过程提出来，然后让不同的子类去实现这个构造过程。产生不同的产品。这就是建造者模式，它类似于一个对象工厂，通过不同的构造过程产生不同的对象。这个和工厂模式比较类似，但也有区别。

java君所在的公司没有一个汉堡店，只卖鸡排堡和鸡腿堡。但是他们的原料很神奇，在汉堡中放的顺序不同，就会产生不同的口味。所以深受大家的喜欢。 汉堡店店长希望可以造出来一个系统，这个系统可以生产出各种各样的鸡排堡和鸡腿堡。这种情况就属于产品的生产过程比较复杂，需要再生产的时候调用原料生产的方法，并且不同的调用顺序还会产生不同的产品。

解决方案

Product产品类

Builder建造者类

ConcreteBuilder类

Director指挥类

如果产品的内部过于复杂，会产生需要定义很多具体建造者来适应这些变化的情况，导致系统变的很庞大而不容易管理。

区别

工厂方法模式(Factory method Pattern)是一种实现了’工厂‘概念的设计模式。就像其它创建型模式一样，她也是在处理不确定对象具体类型的情况下，创建对象的问题。工厂方法的实质：定义一个创建对象的接口，但让实现这个接口的类来决定实例哪个类。工厂方法让类的实例化推迟到子类中进行。（维基百科）

工厂方法模式是一种创建型模式。这个模式提供了一个接口，让实现这个接口的类决定实例化哪一个类，也就是说工厂方法模式将对象的调用者和对象的创建进行分离。 调用者不用考虑对象是怎么被创建的。

java君所在的餐厅最近推出了几款披萨，分别是培根披萨，鲜虾披萨，火腿披萨。在客人点披萨的时候，服务员会通知厨师去做一个披萨，然后服务员上菜。 服务员不用去管比萨是怎么做出来的。他只知道将客人的需求递给厨师，剩下的由厨师来完成就可以。

解决方案

我们在用jdbc进行数据库连接的时候,我们获取连接的时候用getConnection方法直接获取,而不用了解具体的获取过程.当数据库从oracle变成mysql的时候,我们写数据库的操作语言根本不用变化.因为底层的数据库连接获取被jdbc屏蔽了.

Product抽象产品

ConreteProduct具体产品

Factory工厂

Concrete具体工厂

子主题 1

封装良好,代码结构清晰.

获取一个对象只需要知道这个类的约束条件即可.

降低了不同模块之间的耦合

工厂方法模式扩展性很高.如果有了新的产品.只需要添加一个抽象产品的抽象类,然后稍微修改一下工厂类中的代码,甚至不需要修改.

符合面向抽象编程的原则,符合迪米特法则,也符合里氏替换原则.

当只有一个工厂的时候,我们没有必要将其实例化,也没有必要再增加一个工厂接口. 我们可以直接将工厂接口删除掉,然后把工厂中创建类的方法声明成静态方法. 直接通过静态方法进行创建对象调用就可以.这是对一般工厂方法模式的缩小.

如此,我们可以声明多个工厂类,每个工厂类对应着不同的产品的实例化

抽象工厂的实质是"提供接口,创建一些列相关或者独立的对象,而不指定这些对象的具体类"(维基百科)

抽象工厂模式其实是工厂方法模式中最一般的,抽象程度最高的一种类型,本质上也是工厂方法模式.

工厂方法模式是为了创建一种产品,而在我们需要产生一族产品的时候,就需要一个更加强大的工具,抽象工厂模式了.

java君餐厅的披萨套餐都是一样的规格,这引起了大家的不满,成年人可以吃完,小孩子吃不完了.所以顾客强烈要求增加小尺寸披萨.

设计方案F4

产品的继承结构

就是在同一个工厂中生产的一族产品

在系统的工厂所提供的具体产品不是某一对象,而是一个产品族的时候,就要考虑抽象工厂模式了.

也就是说,一个对象族,甚至是没有任何关系的一组对象,有共同的约束条件,就可以使用该模式.

不利于产品族的扩展,如果想要添加一个新的产品,需要对接口进行改动,对接口的改动就意味着要改动所有实现该接口的类.这是很可怕的事情

注意

单例模式也叫做单子模式,是常见的一种设计模式,在应用这个设计模式时,单例对象的类必须保证只有一个实例存在.许多时候,整个系统中只需要拥有一个全局对象,这样有利于我们协调系统整体的行为.

单例模式,顾名思义,就是只有一个实例.

java君睡觉的时候,有认床的习惯.就是说,如果不是他的床,他是睡不着的.java君每次想睡觉的时候,就会请求一个床的实例.所以java君打算用单例来获取床.

代码实现

代码实现

Spring的javabean默认是单例的

servlet也是单例的

不过区别就是单例模式要求每次获取的实例都是一样的,而简单工厂模式就没有这种限制.

内存中只有一个实例,减少了内存的开销.

单例模式还可以设置全局的访问点,优化资源访问.

扩展困难

单例模式对测试不友好

单例模式将单例的获取和该类具体业务逻辑写在一个类中,不符合单一职责原则,

装饰者模式，是面向对象编程领域中，一种动态地往一个类中添加新的行为的设计模式。 就功能而言，装饰者模式相比生成的子类更加灵活，这样可以给某个对象而不是整个类添加一些功能。

顾名思义，是用来做装饰的。既然是装饰，就要有被装饰的组件。 我们平常的一些东西，被装饰后，通常会在保留之前功能的基础上，有了新功能， 有了新功能，就是装饰的意义。 在原来的基础上扩展，这种看起来像是继承可以完成的工作。 可是概念中说到，装饰者模式比生成子类更加灵活，可以给某个对象而不是整个类添加一些新的功能。 可见，使用装饰者模式和直接使用继承是不一样的。

java君喜欢吃东西，而且餐厅老板允许他自己定做，可是java君很讲卫生，还讲究食物色香味俱全。有一次他想吃甜点了，他就想去定做一个蛋糕，餐厅已经有一套做蛋糕的流程了。但是他想要在吃cake之前，用紫外线灯照射厨房3个小时。餐厅的工作人员说这个好办。我们再写一个类，然后继承之前的流程，加上一个照射紫外线的新功能就可以。这个类刚写好，java君又想在做好cake之后在cake上面放一些花瓣。他们就继承了原来的加了紫外线照射的流程后加上放花瓣的新功能，这样就产生了两层继承关系。这个以后如果java君还想再添加新功能，又需要继承，这一层层的继承，维护起来很麻烦。牵一发而动全身，耦合性很强。而且这一次如果java君不想照射紫外线，而是想用消毒水，这下子又需要再写一个继承了，然后放花瓣的类又需要重新继承消毒水。我猜想谁都不想去维护这些类，这样显然是不行的。 其实，当你的继承超过两层的时候，就要考虑下是不是设计有问题了。

我们可以用装饰者模式。在一个功能的基础上添加新功能，除了继承，我们还可以使用组合。即把A类当做B类的一个属性，在B类中使用A类的方法。从而实现B类对A类功能的继承。这个就是装饰者模式的基础。

代码实现

IO流

Component接口

ConcreteComponent类

Decorator类

ConcreteDecorator类

可以让装饰类和被装饰类独立发展而不会相互影响，降低了他们之间的耦合性。

装饰者模式可以很方便的动态扩展一个实现类的功能。

多层的装饰复杂度提高，不利于debug。

指对象有某个行为,但是在不同的场景中,该行为有不同的实现算法

基于设计原则

不变的地方是这个行为,变化的地方是行为所需要的算法(策略)

java君、Pascal君、Scala君三个人要去餐厅吃饭,可是呢,他们三个的口味不一样,java君想吃面向对象大餐,Pascal君想吃面向过程大餐,而Scala君想吃函数式大餐,这时候假设你是餐厅服务员,你给每个人点餐的时候,你就这样写了

解决之道

Struts

springmvc

排序的时候，由于不同的需要排序的类的排序规则不一样，也就是策略不一样，

所以我们把策略封装到客户部分，也就是具体需要排序的类中，也就是让具体需要排序的类实现Comparable接口，

然后在传入到排序的算法中的时候，排序的算法在比较两个元素的先后顺序的时候直接调用其compareTo方法，

根据多态，他调用的其实是具体传入的compareTo方法。也就是封装到子类中的具体的比较策略，这样就能实现了具体的排序

Context

Strategy

ConcreteStrategy

实现一族算法，并将每一个算法都封装起来，使其相互交换

因为客户端需要了解不同算之间的区别，选择合适的算法

针对接口编程，而不是针对实现编程

Collections.sort (List<T> ,list)

Collections.sort(List<T> list ,Comparator<? super T> c )

模板方法模式定义了一个算法的步骤,并允许子类别为一个或者多个步骤提供其实践方式。在子类别在不改变算法架构的情况下，重新定义算法中的某些步骤（维基百科）

在这个模式中，算法的步骤是确定的。（对第一句的理解） 相当于父类中有算法步骤，但是把具体的算法步骤延迟到子类中去实现。（对第二句的理解） 如此：就实现了算法步骤和算法步骤的具体实现分离。 如果再有一份新的算法的实现，就再写一个子类就可以了。

既然是步骤，就是有顺序

Pascal君和Java君点完餐之后，想要吃饭。 他们的吃饭步骤如下： 准备餐具，吃饭，收拾餐具。 但是pascal君和java君准备的餐具不同，吃饭的方式当然也不一样，并且pascal君不喜欢收拾餐具。而java君每次吃饭后都要自己收拾餐具。

活用场景

分析异同： 同：吃饭步骤三步。 异：三个步骤的具体实现不同 将相同的步骤抽离出来，就属于模板方法。 如此：我们将其封装到父类中，这个父类可以是一个抽象类，然后让子类去继承父类，然后子类去具体实现具体的被模板调用的方法，这个就把变化的部分和不变的部分分离开了。

代码实现

servlet中对一个请求进行具体的业务逻辑处理。 是调用了HttpServlet中的service方法，然后service方法根据不同的请求分发到具体的方法中，而具体的业务逻辑则由用户去进程HttpServlet类去实现

模板类

具体实现类

符合开闭原则

问题

命令模式将请求封装成一个对象，从而使用不同的请求对客户端进行参数化，使用求情队列，或者记录请求日志，并且支持撤销操作。

从定义上来看，他是把命令封装成了对象，命令就是指令，是上级发给下级的，既然有命令，就会有上下级的层次关系，命令是下发给下层人员去执行的。 所以命令模式中有决策者和执行者。

所谓的使用请求将客户端参数化，就是将执行者的命令参数化，也就是将命令封装成了对象。

至于队列和记录日志，就是在基础的命令模式上的扩展

例如：使用遥控控制电视机

我们使用遥控器的时候，做的只是按下某个按钮，然而这个按钮按下之后，遥控器发送的是什么样的红外线信号，我们不得而知，信号传到电视中之后被谁获取了我们也不知道。获取之后有什么样的操作，我们更不得而知。

我们只知道，我们按下这个按钮，电视做出了一些变化，也就是说，我们发出某个指令，获得了一些反馈信息

java君比较勤奋，而且有收拾盘子的好习惯。所以他被餐厅老板奖励，可以让java君去定做一些菜品，这下java君高兴坏了。但不久之后他就发现问题了。 比如：java君想吃焗盐鸡。然后他走到餐厅后，找到采购员，然后命令她去采购新鲜的鸡和粗盐。采购回来之后，他又找到负责宰鸡的师傅，帮忙杀掉黄毛鸡，然后找到厨师师傅帮忙给抹上细盐，包上吸油纸，锡纸，埋到粗盐中。最后找到烘烤师傅，帮忙烤熟。这样他才得到一只香喷喷的盐焗鸡。 不过这样太麻烦了呀。java君只是一个食客，结果他想吃一只鸡就需要前前后后联系那么多的人。并且java君有时候还想去吃黄焖鸡，这样就要去联系其他的人了。所以，他很厌烦。

解决之道

Invokeer

Command

Receiver

对命令的封装，将发出命令和执行命令两个责任解耦。 每个命令都是一个操作，请求的一方发出命令，然后执行者收到命令，执行命令。

使用命令模式，调用者和接受者之间没有任何依赖关系。 调用者进行调用的时候，只需要调用execute()方法即可，而不用关心具体是哪一个接受者

Command子类容易扩展

命名模式支持撤销操作。

命令模式可和其他模式进行联合

在Command命令复杂的时候，会造成Command子类膨胀

请求队列

请求日志

是一种软件设计模式，它包含了一些命令对象和一系列的处理对象。 每一个处理对象决定它能出处理哪些命令对象，它也知道如何将它不能处理的命令对象传递给该链中的下一个处理对象。 该模式还描述了往该处理链的末尾添加新的处理对象的方法。

责任链模式包含了命令对象和处理对象，是该模式中的两个角色。 既然是责任链，那么责任链是怎么表现出来的呢？概念中提到，每一个处理对象决定它能处理的那些对象，这就是责任的体现。 我如果能处理这个对象，那么我就对这个对象负责，如果我不能处理，我就把它叫给其他的对象。如此，就形成了一条处理链。

java君太厉害了，以至于java君所在的公司想给他报销餐费，这个公司有个奇怪的规定，项目经理只能报销<=500的餐费，部门经理只能报销<=1000且>=500的餐费，总经理只能报销1000以上的餐费，这一次，java君在享用了自己制定的菜品之后，希望各位领导大大们给他报销，那么大家可能会这样写

这样大量的if-else语句嵌套，使代码的可读性大大降低了，不美观，体现不出来代码的艺术感，并且如果公司规定变化了。这个if-else结构就得跟着变化。不符合开闭原则。

需求分析

设计方案

代码实现

Client

Handler

Concretehandler

核心是链

我们在实际项目中用到的大多数是不纯的责任链

设计模式是为项目服务的，项目中怎么用着方便就怎么用，不要被设计模式所限制，造成思维僵化。

将请求和处理分开了，请求者可以不用知道是谁处理的。 处理者也可以不知道请求者的全部。 两者解耦，提高了 系统的灵活性。

每次请求都是从链头遍历到链尾，造成了性能问题和调试的不方便

在实际应用中，我们经常回去控制链中节点的数量。避免出现超长的链。

Client封装了一个Command，传给Invoker，Invoker调用Command的执行方法，然后交给Receiver具体执行。如果结合了责任链模式，就可以让这个命令在链中进行传递，让对该命令负责的处理者对其进行处理。从而大大增加了系统的灵活性。

让一个对象在其内部状态改变的时候，其行为也随之改变。状态模式需要对每一个系统可能获得的状态创立一个状态类的子类。当系统的状态变化后时，系统便改变所有的子类。（维基百科）

状态模式，可见，有状态的概念。状态就是事物的实时属性，是可以变化的。在程序设计上，状态的变化，意味着行为可能发生变化，这样的话，我们可能会遇到某个行为在不同的状态下会有不同的表现(这个听起来可以用策略模式或者模板方法模式)。在某个状态下进行某个动作之后，还有可能会变化该状态。这样的话，我们可能会需要若干个if-else语句，或者switch语句。这样写就会发生状态的耦合，不利于修改。所以要用状态模式。

java君太厉害了，被餐厅聘请为架构师。java君任职第一天，老板就有了新任务，他们准备添加一台自动售货机，贩卖java咖啡和面向对象速食套餐。而且要插入会员卡进行消费。如此，java君开始设计了。 如果这个人没有插卡，是不能买东西的。插卡之后，可以买东西，可以退卡。买完东西可以接着卖可以退卡。退卡之后可以插卡接着买。

解决方案

TCP监听，TCP连接有三个状态。 这三个状态按照顺序循环切换，在不同的状态下会有不同的行为。

不过，在具体的项目中，通常不是和TCP的状态这样只能切换到单一的状态，我们经常会遇到的是某个状态可以切换到很多其他的状态

Status

ConcreteStatus

Context

避免了大量的switch语句和if-else语句，使得结构更加清晰，避免了程序的复杂，提高了整个系统的可维护性。

如果一个事物有多个状态，就会产生类爆炸。 大量的子类使得系统不是那么容易管理。

两者共同点

两者不同点