通过阅读《大话设计模式》这本书，初步了解了设计模式，以及我以前对设计模式的一些误解。
几条心得如下：
1.设计模式并不只是一种方法，更是一种思想。
2.设计模式和具体的语言没有关系，学习设计模式最重要的目的就是要建立面向对象的思想，尽可能地面向接口编程，高内聚，低耦合，使设计的程序可复用。
3.在进行程序设计时，不要总想着往某个设计模式上套，这是没有真正掌握设计模式思想的表现。
4.学习设计模式，一定要勤学多练。
创建型模式
1.工厂方法模式
使用时机：当在代码中使用new来创建比较复杂的对象时，可以考虑使用工厂方法模式，
优点：具体的工厂类负责对象的创建，客户端负责对象的调用。
如果有新的产品加进来，只需新增一个具体的创建产品工厂类和具体的产品类即可，不会影响原来的代码，后期维护更容易，增强了系统的可扩展性。
缺点：需要额外编写代码，增加工作量。
2.抽象工厂模式
使用时机：当系统需要创建一系列相互关联的对象时，需要使用抽象工厂模式。
优点：具体的工厂类负责对象的创建，客户端负责对象的调用，从而明确各个类的职责。
当一系列相互关联的产品被设计到一个工厂类里后，客户端的调用将会变得非常简单，而且，如果要更换这一系列的产品，只需要更换一个工厂类即可。
缺点：如果有新的产品加进来，则需要修改抽象工厂类的设计，并同时修改实现这个抽象工厂类的具体工厂类，需要额外编写代码，增加了工作量。
3.创建者模式
使用时机：当系统需要创建一个复杂的对象，而且这个复杂的对象组装起来比较麻烦时，就可以使用创建者模式。
优点：在创建者模式中，客户端不再负责对象的创建组装，而是把这个常见的责任交给具体的创建者类，吧组装的负责责任交给组装类，客户端只负责对象的调用，从而明确了各个类的职责。
缺点：虽然利用创建者模式可以创建出不同的类型的产品，但是如果产品之间的差异巨大，则需要编写多个创建者类才能实现，这时如果给结合工厂模式就更好了。
4.原型模式
使用时机：当系统需要创建的对象是动态加载的，而且产品具有一定层次时，需要使用原型模式。
优点：在此模型中，可以动态地添加产品类，而且对整体结构没有影响。
缺点：由于对原型类中的每个类配备一个克隆的方法，这就需要在设计类时通盘考虑，因为在已有类的基础上来添加clone操作是比较困难的，而且原型模式在实现深层次的复制时，需要编写一定量的代码。
5.单例模式
使用时机：当系统需要一个类只有一个实例时，就需要使用单例模式。
优点：在单例模式中，客户调用类的实例时。只能调用一个公共的接口，这就为整个开发团队提供了一个共享的概念。
缺点：实现单例模式的类在实例化后，不能被别的类继承，在分布式系统中，当系统中的单例类被复制运行在多个虚拟机下是，在每一个虚拟机下都会创建一个实例对象，此时如果想知道具体哪个虚拟机下运行着多少个单例对象是很困难的，而且单例类很难实现序列化。