我们使用设计模式目的：
- a)缩短开发时间；
- b)降低维护成本；
- c)在应用程序之间和内部轻松集成。具体什么时候使用何种设计模式还得因项目而异。
设计模式的分类：
总体来说设计模式分为三大类：
设计模式的六大原则：
总原则：开闭原则（Open Close Principle） 开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类等，后面的具体设计中我们会提到这点。
- 1、单一职责原则
不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，如若不然，就应该把类拆分。
- 2、里氏替换原则（Liskov Substitution Principle）
里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科 历史替换原则中，子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范的接口与外界交互，子类不应该随便破坏它。
- 3、依赖倒转原则（Dependence Inversion Principle）
这个是开闭原则的基础，具体内容：面向接口编程，依赖于抽象而不依赖于具体。写代码时用到具体类时，不与具体类交互，而与具体类的上层接口交互。
- 4、接口隔离原则（Interface Segregation Principle）
这个原则的意思是：每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离的接口，比使用单个接口（多个接口方法集合到一个的接口）要好。
- 5、迪米特法则（最少知道原则）（Demeter Principle）
就是说：一个类对自己依赖的类知道的越少越好。也就是说无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当被依赖的类变化时，才能最小的影响该类。 最少知道原则的另一个表达方式是：只与直接的朋友通信。类之间只要有耦合关系，就叫朋友关系。耦合分为依赖、关联、聚合、组合等。我们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。我们要求陌生的类不要作为局部变量出现在类中。
- 6、合成复用原则（Composite Reuse Principle）
原则是尽量首先使用合成/聚合的方式，而不是使用继承。
工厂模式：
- 概述：
属于创建型设计模式，需要生成的对象叫做产品 ，生成对象的地方叫做工厂 。
- 使用场景：
在任何需要生成复杂对象的地方，都可以使用工厂方法模式。 直接用new可以完成的不需要用工厂模式
- 实际不能算作一种设计模式，它引入了创建者的概念，将实例化的代码从应用代码中抽离，在创建者类的静态方法中只处理创建对象的细节，后续创建的实例如需改变，只需改造创建者类即可，但由于使用静态方法来获取对象，使其不能在运行期间通过不同方式去动态改变创建行为，因此存在一定局限性。
- 定义了一个创建对象的接口，但由实现类决定要实例化的类是哪一个，工厂方法让类把实例化推迟到了实现类。
- 提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类
例子，可以查看：工厂的例子
/** * 简单工厂 * * 简单工厂实际不能算作一种设计模式，它引入了创建者的概念，将实例化的代码从应用代码中抽离， * 在创建者类的静态方法中只处理创建对象的细节，后续创建的实例如需改变，只需改造创建者类即可， * 但由于使用静态方法来获取对象，使其不能在运行期间通过不同方式去动态改变创建行为，因此存在一定局限性。 * * 拿铁、美式咖啡、卡布奇诺等均为咖啡家族的一种产品 * 咖啡则作为一种抽象概念 */
抽象类：咖啡
子类： 中式产品：拿铁、卡布奇诺、奶茶 美式产品：美式咖啡、卡布奇诺、可乐
工厂：中国，美国
//abstract class Coffee{ abstract class Coffee extends Drink{ public abstract String getName(); } class Americano extends Coffee { public String getName() { return "美式咖啡"; } } class Cappuccino extends Coffee { public String getName() { return "卡布奇诺"; } } class Latte extends Coffee { public String getName() { return "拿铁"; } } public class SimpleFactory { /** * 通过类型获取Coffee实例对象 * @param type 咖啡类型 * @return */ public static Coffee createInstance(String type){ if("americano".equals(type)){ return new Americano(); }else if("cappuccino".equals(type)){ return new Cappuccino(); }else if("latte".equals(type)){ return new Latte(); }else{ throw new RuntimeException("type["+type+"]类型不可识别，没有匹配到可实例化的对象！"); } } public static void main(String[] args) { Coffee latte = SimpleFactory.createInstance("latte"); System.out.println("创建的咖啡实例为:" + latte.getName()); Coffee cappuccino = SimpleFactory.createInstance("cappuccino"); System.out.println("创建的咖啡实例为:" + cappuccino.getName()); } }/** * 工厂方法模式 *
- 定义了一个创建对象的接口，但由实现类决定要实例化的类是哪一个，工厂方法让类把实例化推迟到了实现类。
- 场景延伸：不同地区咖啡工厂受制于环境、原料等因素的影响，制造出的咖啡种类有限。 * 中国咖啡工厂仅能制造卡布奇诺、拿铁，而美国咖啡工厂仅能制造美式咖啡、拿铁。 *
- 定义一个抽象的咖啡工厂 */
abstract class CoffeeFactory { public abstract Coffee[] createCoffee();}class ChinaCoffeeFactory extends CoffeeFactory { public Coffee[] createCoffee() { return new Coffee[]{new Cappuccino(), new Latte()}; }}class AmericaCoffeeFactory extends CoffeeFactory { public Coffee[] createCoffee() { return new Coffee[]{new Americano(), new Latte()}; }}public class FactoryMethodTest { static void print(Coffee[] c){ for (Coffee coffee : c) { System.out.println(coffee.getName()); } } public static void main(String[] args) { CoffeeFactory chinaCoffeeFactory = new ChinaCoffeeFactory(); Coffee[] chinaCoffees = chinaCoffeeFactory.createCoffee(); System.out.println("中国咖啡工厂可以生产的咖啡有："); print(chinaCoffees); CoffeeFactory americaCoffeeFactory = new AmericaCoffeeFactory(); Coffee[] americaCoffees = americaCoffeeFactory.createCoffee(); System.out.println("美国咖啡工厂可以生产的咖啡有："); print(americaCoffees); }}
- 抽象工厂 * *提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。 *在上述的场景上继续延伸：咖啡工厂做大做强，引入了新的饮品种类：茶、 碳酸饮料。 *中国工厂只能制造咖啡和茶，美国工厂只能制造咖啡和碳酸饮料。 *如果用上述工厂方法方式，除去对应的产品实体类还需要新增2个抽象工厂（茶制造工厂、碳酸饮料制造工厂）， *4个具体工厂实现。随着产品的增多，会导致类爆炸。所以这里引出一个概念产品家族， *在此例子中，不同的饮品就组成我们的饮品家族， 饮品家族开始承担创建者的责任，负责制造不同的产品。 * * * 抽象的饮料产品家族制造工厂
单利模式：
单例模式确保某个类只有一个实例，而且自行实例化并向整个系统提供这个实例。
- 单例模式特点：
1、单例类只能有一个实例。 2、单例类必须自己创建自己的唯一实例。 3、单例类必须给所有其他对象提供这一实例
- 线程安全的问题：
1.在获取单例的时候，要保证不能产生多个实例 2.在使用单例对象的时候，要注意单例对象内的实例变量是会被多线程共享的，推荐使用无状态的对象，不会因为多个线程的交替调度而破坏自身状态导致线程安全问题。
- 饿汉式单例：
代码：
public class Singleton { // 私有构造方法 private Singleton() {} private static Singleton single = new Singleton(); // 静态工厂方法 public static Singleton getInstance() { return single; } }饿汉式单例在类加载初始化时，就创建好一个静态的对象供外部使用，除非系统重启，这个对象不会改变，所以本身就是线程安全的。 Singleton通过将构造方法限定为private避免了类在外部被实例化，在同一个虚拟机范围内，Singleton的唯一实例只能通过getInstance()方法访问
- 懒汉式单例：
代码：
public class Singleton2 { // 私有构造方法 private Singleton2() {} private static Singleton2 single = null; public static Singleton2 getInstance() { if(single == null){ single = new Singleton2(); } return single; } }这种写法起到了Lazy Loading的效果，但是只能在单线程下使用。如果在多线程下， 一个线程进入了 if (singleton ==null)判断语句块，还未来得及往下执行， 另一个线程也通过了这个判断语句，这时便会产生多个实例。所以在多线程环境下不可使用这种方式。
- 在下面几个场景中适合使用单例模式：
1、有频繁实例化然后销毁的情况，也就是频繁的 new 对象，可以考虑单例模式； 2、创建对象时耗时过多或者耗资源过多，但又经常用到的对象； 3、频繁访问 IO 资源的对象，例如数据库连接池或访问本地文件；
【本文来自：台湾服务器 http://www.558idc.com/tw.html 复制请保留原URL】