现在有一只羊tom，姓名为: tom, 年龄为：1，颜色为：白色，请编写程序创建和tom羊属性完全相同的10只羊。
传统方式，通过new一个对象，然后通过get方法获取属性，创建新对象。
优点是比较好理解，简单易操作。在创建新的对象时，总是需要重新获取原始对象的属性，如果创建的对象比较复杂时，效率较低。 总是需要重新初始化对象，而不是动态地获得对象运行时的状态, 不够灵活
改进的思路分析，Java中Object类是所有类的根类，Object类提供了一个clone()方法，该方法可以将一个Java对象复制一份，但是需要实现clone的Java类必须要实现一个接口Cloneable， 该接口表示该类能够复制且具有复制的能力 => 原型模式。
原型模式(Prototype模式)是指：用原型实例指定创建对象的种类，并且通过拷贝这些原型，创建新的对象
原型模式是一种创建型设计模式，允许一个对象再创建另外一个可定制的对象， 无需知道如何创建的细节
工作原理是:通过将一个原型对象传给那个要发动创建的对象，这个要发动创建的对象通过请求原型对象拷贝它们自己来实施创建，即对象.clone()
浅拷贝的介绍
对于数据类型是基本数据类型的成员变量，浅拷贝会直接进行值传递，也就是将该属性值复制一份给新的对象。
对于数据类型是引用数据类型的成员变量，比如说成员变量是某个数组、某个类的对象等，那么浅拷贝会进行引用传递，也就是只是将该成员变量的引用值(内存地址)复制一份给新的对象。因为实际上两个对象的该成员变量都指向同一个实例。在这种情况下，在一个对象中修改该成员变量会影响到另一个对象的该成员变量值
前面我们克隆羊就是浅拷贝
浅拷贝是使用默认的 clone()方法来实现 sheep = (Sheep) super.clone();
深拷贝基本介绍
复制对象的所有基本数据类型的成员变量值
为所有引用数据类型的成员变量申请存储空间，并复制每个引用数据类型成员变量所引用的对象，直到该对象可达的所有对象。也就是说，对象进行深拷贝要对整个对象进行拷贝
深拷贝实现方式:
重写clone方法来实现深拷贝
通过对象序列化实现深拷贝(推荐)
创建新的对象比较复杂时，可以利用原型模式简化对象的创建过程，同时也能够提高效率
不用重新初始化对象，而是动态地获得对象运行时的状态
如果原始对象发生变化(增加或者减少属性)，其它克隆对象的也会发生相应的变化， 无需修改代码
在实现深克隆的时候可能需要比较复杂的代码
缺点：需要为每一个类配备一个克隆方法，这对全新的类来说不是很难，但对已有的类进行改造时，需要修改其源代码，违背了ocp原则，这点请同学们注意.
盖房项目需求
需要建房子：这一过程为打桩、砌墙、封顶
房子有各种各样的，比如普通房，高楼，别墅，各种房子的过程虽然一样，但是要求不要相同的.
请编写程序，完成需求.
传统方式解决
优点是比较好理解，简单易操作。
缺点：
设计的程序结构，过于简单，没有设计缓存层对象，程序的扩展和维护不好. 也就是说，这种设计方案，把产品(即：房子) 和创建产品的过程(即：建房子流程) 封装在一起，耦合性增强了。
解决方案：将产品和产品建造过程解耦 => 建造者模式.
建造者模式（Builder Pattern） 又叫生成器模式，是一种对象构建模式。它可以 将复杂对象的建造过程抽象出来（抽象类别），使这个抽象过程的不同实现方法可以构造出不同表现（属性）的对象。建造者模式是一步一步创建一个复杂的对象，它允许用户只通过指定复杂对象的类型和内容就可以构建它们，用户不需要知道内部的具体构建细节。
建造者模式的四个角色
Product（产品角色）： 一个具体的产品对象。
Builder（抽象建造者）： 创建一个Product对象的各个部件指定的接口/抽象类。
ConcreteBuilder（具体建造者）： 实现接口，构建和装配各个部件。
Director（指挥者）： 构建一个使用Builder接口的对象。它主要是用于创建一个 复杂的对象。它主要有两个作用，一是：隔离了客户与对象的生产过程，二是： 负责控制产品对象的生产过程。
Appendable接口定义了多个append方法(抽象方法), 即Appendable为抽象建造者, 定义了抽象方法
AbstractStringBuilder实现了Appendable接口方法，这里的AbstractStringBuilder已经是建造者，只是不能实例化
StringBuilder 即充当了指挥者角色，同时充当了具体的建造者，建造方法的实现是由AbstractStringBuilder完成, 而StringBuilder继承了 AbstractStringBuilder
客户端(使用程序)不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象
每一个具体建造者都相对独立，而与其他的具体建造者无关，因此可以很方便地替换具体建造者或增加新的具体建造者，用户使用不同的具体建造者即可得到不同的产品对象
可以更加精细地控制产品的创建过程 。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程
增加新的具体建造者无须修改原有类库的代码，指挥者类针对抽象建造者类编程， 系统扩展方便，符合 “开闭原则”
建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制。
如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化， 导致系统变得很庞大，因此在这种情况下，要考虑是否选择建造者模式.
抽象工厂模式VS建造者模式
抽象工厂模式实现对产品家族的创建，一个产品家族是这样的一系列产品：具有不同分类维度的产品组合，采用抽象工厂模式不需要关心构建过程，只关心什么产品由什么工厂生产即可。而建造者模式则是要求按照指定的蓝图建造产品，它的主要目的是通过组装零配件而产生一个新产品。
现实生活中的适配器例子，泰国插座用的是两孔的（欧标），可以买个多功能转换插头 (适配器) ，这样就可以使用了。
适配器模式(Adapter Pattern)将某个类的接口转换成客户端期望的另一个接口表示，主的目的是兼容性，让原本因接口不匹配不能一起工作的两个类可以协同 工作。其别名为包装器(Wrapper)
适配器模式属于结构型模式
主要分为三类：类适配器模式、对象适配器模式、接口适配器模式
工作原理
适配器模式：将一个类的接口转换成另一种接口。让原本接口不兼容的类可以兼容。从用户的角度看不到被适配者，是解耦的。用户调用适配器转化出来的目标接口方法，适配器再调用被适配者的相关接口方法 。用户收到反馈结果，感觉只是和目标接口交互。
Java是单继承机制，所以类适配器需要继承被适配类这一点算是一个缺点, 因为这要求目标类必须是接口，有一定局限性;。被适配类的方法在Adapter(适配器类)中都会暴露出来，也增加了使用的成本。由于其继承了被适配类，所以它可以根据需求重写被适配类的方法，使得Adapter(适配器类)的灵活性增强了。
基本思路和类的适配器模式相同，只是将Adapter类作修改，不是继承被适配类，而是持有被适配类的实例，以解决兼容性的问题。 即：持有被适配类，实现目标类接口， 完成被适配类到目标类的适配。根据“合成复用原则”，在系统中尽量使用关联关系来替代继承关系。对象适配器模式是适配器模式常用的一种
对象适配器和类适配器其实算是同一种思想，只不过实现方式不同。 根据合成复用原则，使用组合替代继承， 所以它解决了类适配器必须继承被适配类的局限性问题，也不再要求目标必须是接口。使用成本更低，更灵活。
接口适配器模式，一些书籍称为：适配器模式(Default Adapter Pattern)或缺省适配器模式。当不需要全部实现接口提供的方法时，可先设计一个抽象类实现接口，并为该接口中每个方法提供一个默认实现（空方法），那么该抽象类的子类可有选择地覆盖父类的某些方法来实现需求。适用于一个接口不想使用其所有的方法的情况。
模式SpringMVC
适配器模式的注意事项和细节
三种命名方式，是根据 src是以怎样的形式给到Adapter（在Adapter里的形式）来命名的。
类适配器：以类给到，在Adapter里，就是将src当做类，继承。对象适配器：以对象给到，在Adapter里，将src作为一个对象持有。
接口适配器：以接口给到，在Adapter里，将src作为一个接口实现。
Adapter模式最大的作用还是将原本不兼容的接口融合在一起工作。
实际开发中，实现起来不拘泥于我们讲解的三种经典形式。
现在对不同手机类型的 不同品牌实现操作编程(比如: 开机、关机、上网，打电话等)， 如图:
传统方案解决手机使用问题(类图)
传统方案解决手机操作问题分析
扩展性问题(类爆炸)，如果我们再增加手机的样式(旋转式)，就需要增加各个品牌手机的类，同样如果我们增加一个手机品牌，也要在各个手机样式类下增加。
违反了单一职责原则，当我们增加手机样式时，要同时增加所有品牌的手机，这 样增加了代码维护成本.。
解决方案-使用桥接模式。
桥接模式(Bridge模式)是指：将实现与抽象放在两个不同的类层次中，使两个层 次可以独立改变。是一种结构型设计模式 ,Bridge模式基于类的最小设计原则，通过使用封装、聚合及继承等行为让不同的类承担不同的职责。它的主要特点是把抽象(Abstraction)与行为实现 (Implementation)分离开来，从而可以保持各部分的独立性以及应对他们的功能 扩展。
实现了抽象和实现部分的分离，从而极大的提供了系统的灵活性，让抽象部分和实现部分独立开来，这有助于系统进行分层设计，从而产生更好的结构化系统。
对于系统的高层部分，只需要知道抽象部分和实现部分的接口就可以了，其它的部分由具体业务来完成。
桥接模式替代多层继承方案，可以减少子类的个数，降低系统的管理和维护成本。
桥接模式的引入增加了系统的理解和设计难度，由于聚合关联关系建立在抽象层， 要求开发者针对抽象进行设计和编程
桥接模式要求正确识别出系统中两个独立变化的维度，因此其使用范围有一定的局限性，即需要有这样的应用场景。
对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统，桥 接模式尤为适用.
常见的应用场景:
-JDBC驱动程序
-银行转账系统
转账分类: 网上转账，柜台转账，AMT转账
转账用户类型：普通用户，银卡用户，金卡用户..
-消息管理
消息类型：即时消息，延时消息
消息分类：手机短信，邮件消息，QQ消息...