设计模式

[color=red]设计模式[/color]


[color=red]为什么要使用设计模式？[/color]

设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。


[color=red]设计模式的原则[/color]
1、"开－闭"原则，可以理解为“对扩展开放，而对修改关闭”。摸块应尽量在不修改原(是"原"，指原来的代码)代码的情况下进行扩展。

2、"里氏代换原则 "，用父类或者接口来引用子类对象，里氏代换原则是继承复用的一个基础。

3、"合成复用原则"，少用继承多用合成关系来实现。避免修改类时候，"牵一发而动全身"，要把波动限制在尽量小的范围。合成：更强的整体与部分，拥有相同的生命周期。一个合成而成的对象完全拥有其组成部分的支配权，包含销灭与创建。

4、依赖倒转原则，抽象不应该依赖于实现，实现应当依赖于抽象。要针对接口编程，而不是针对实现编程。

5、接口隔离原则，定制服务的例子，每一个接口应该是一种角色，不多不少，不干不该干的事，该干的事都要干

6、米特法则，最少知识原则。不要和陌生人说话。在对其它对象的引用上，一个类对其它对象的引用应该降到最低。在类的设计上，只要有可能，一个类应当设计成不变类。在类的结构设计上，每一个类都应当尽量降低成员的访问权限。一个类不应当public自己的属性，而应当提供取值和赋值的方法让外界间接访问自己的属性，减少实现类的可导性。


[color=red]怎么选择设计模式[/color]
首先，目前设计模式分为创建模式，结构模式，行为模式。

所谓创建模式，比较容易理解。
[color=red]factory工厂模式: [/color]
分为简单工厂模式与抽象工厂模式，区别在于简单工厂模式只是简单地创建对象，因为工厂后续产品种类增多就会导致代码改动很大，它扩展性不强。一般代码改动很少，很简单的，可以考虑使用。抽象工厂模式，字里行间已提到了抽象，第一、抽象工厂产品的种类。 第二、抽象工厂产品种类的共同行为与属性。第三、定义工厂的具体产品并实现其抽象接口。第四，定义具体工厂类进行生产产品。

工厂模式其实与bridge（桥接）模式在类抽象思维上差不多。

工厂模式用的很多，我一般建议使用抽象模式，简单工厂模式在简单应用场景才能适用。

理论应用
有人问百度：用简单工厂来创建对象和用new创建对象相比好处有哪些？
有人回答：我不知道你认真研究过设计模式没有?之所以要使用模式思想,是因为要遵循开闭原则,开闭原则就是对修改关闭对扩展开放.开闭原则有五种实现途径,我只提跟你问题相关的一种.也就是开闭原则中比较重要的一条原则:依赖倒转原则,什么是依赖,如果不是很明白你可以先研究一下面向对象之间的几种耦合关系.所谓依赖倒转原则就是,依赖于抽象而不依赖于实现.为什么要依赖于抽象而不依赖于实现,很简单的问题,但要解释我又要引入其他两种开闭原则的实现途径,一、迪米特法则 大意是：将可变性的耦合效应或者说传导效应降到最低，二、里氏代换原则，大意是父类出现的地方子类可以取而代之。依赖于抽象时我们可以很容易的对系统进行扩展，只要是继承自相关接口或者抽象类的新业务，都可以很顺利的插入到系统中去，且对客户端没有任何影响，这就是里氏代换。如果我们依赖抽象，我们就可以减少实现类中可变性的传导问题，不至于动一处而动全身，这就使迪米特法则。好，下面开始正面回答你的问题，new关键字其实是违反依赖倒转原则的一种设计，如果你用new，那么你只能new 具体类型，这样一来就是抽象依赖于实现，显然不符合开闭原则。为了最大限度的遵循开闭原则，我们就要采用各种设计模式去将这种不正确的依赖方向封装起来，只给外界提供正确的依赖方向。

其实，new 对象还是很多，存在即合理，new 对象是有其应用场景的，设计不能过分设计。

[color=red]prototype原型模式：[/color]
复制原型对象创建实例，根据对象克隆深度层次的不同，有浅度克隆与深度克隆。浅度克隆，其实创建了一个新引用对象，其实指向还是原来的实例。深度克隆，则重新创建一个一摸一样的实例对象。原型模式应用场景还是比较多，也不难理解。


[color=red]Builder生成器模式：[/color]
　一. 生成器模式简介
　　生成器模式也有称为建造者模式。生成器模式的意图在于将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示（GoF）。在软件设计中，有时候面临着一个非常复杂的对象的创建工作。这个复杂的对象通常可以分成几个较小的部分，由各个子对象组合出这个复杂对象的过程相对来说比较稳定，但是子对象的创建过程各不相同并且可能面临变化。根据OOD中的OCP原则，我们自然应该对这些子对象的创建过程进行变化封装。
　　这就是生成器模式的思路。定义一个抽象的建造者的角色（Builder），规定所有具体的建造者都应该具有的功能——这些功能就是如何创建复杂对象的某个特定部分（子对象），而具体如何创建子对象有具体的创建者实现。再定义一个指导者的角色，它把创建者作为工具，知道如何使用这个工具来创建复杂对象。这样，客户在需要创建这个复杂对象的时候，只需要给指导者一个具体的创建者就可以了。至于具体创建者如何创建子对象的细节以及这些子对象之间的差异，不是指导者，也不是客户关心的。
　　二. 生成器模式实例
　　还以汽车制造作为例子。假定汽车由三个部件组装而成：车身、引擎和轮胎，每个部件的制造以及最后的组装过程都很复杂。一个品牌汽车销售商一般不会自己来完成这些繁琐的过程，而是把它交给汽车零部件制造商。实际上有许多汽车零部件制造商，可以完成不间部件的生产和组装过程。
那么，客户是怎么获得一辆汽车的呢？首先，客户需要选定一个汽车制造商（比如某品牌），然后在选择一个汽车销售商（经纪人）为我们服务。然后，我们只需要告诉销售商我们需要哪个制造商的汽车，接下来，由销售商来代替我们监督汽车制造商一步一步为我们生产所需要的汽车（可以考虑订单式生产方式或对某部分特殊定制，如加长车身）。汽车生产完成后，由汽车制造厂提车就可以了。
在于将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。表示的变化不影响组装的过程，表示的创建变化遵循关闭原则需要进行封装。

[color=red]Singleton单列模式[/color]
Singleton模式主要作用是保证在Java应用程序中，一个类Class只有一个实例存在。
Singleton也能够被无状态化。提供工具性质的功能， Singleton模式就为我们提供了这样实现的可能。使用Singleton的好处还在于可以节省内存，因为它限制了实例的个数，有利于Java垃圾回收（garbage collection）。
如果你的应用基于容器，那么Singleton模式少用或者不用，可以使用相关替代技术。