设计模式学习
参照《大话设计模式》学习（PDF文件），实现每个设计模式的案例，以及总结设计原则
同步参照网络上其他人的练习记录，争取暑假初步理解设计模式，并能简单应用
-
一个工厂类，一个基类，多个子类
-
用于解决对象的创建问题
-
先提供一个公共的基类，接下来的具体各类继承父类，覆写父类的提供的接口，工厂类提供一个静态方法，根据提供的参数来创建不同的类，然后通过调用工厂类来创建所需要的类
-
程序增加其他需求，则可继续继承父类创建新的类，同时在工厂类中添加对应的创建过程
-
可以理解为女娲造人，女娲表示工厂类，所有人表示基类，男人，女人，机器人表示各个子类，先提供一个人模式，然后根据女娲的想法（参数）来把这个人模型创建成相应的人类型，如果出现一种新类型的人（新增一种子类），则女娲的想法需要添加冠以这中人的信息（工厂类修改添加相应子类信息）
-
缺点是违反了开闭原则， 当对应的子类越来越多时候，工厂类会越来越臃肿，不利于维护。而且工厂类是模式的核心，一旦工厂类出现了问题，则整个模式就会崩溃
-
官方解释：
它定义了算法家族，分别分装起来，让他们之间可以相互替换，此模式让算法的变化，不会影响到使用算法的客户
-
一个上下文类，一个抽象的策略类，多个具体策略
-
多个具体的策略是用来解决同一问题的不同方法，最直接形象的就是排序，可以选择冒泡排序，选择排序等等各种策略，他们的目的都是为了排序，但中间的过程不一样，如过增加一种排序算法，不会影响其他已存在的策略；还有类比的收银台，目的都是收钱，但是可以有多种收钱方式，支付宝，微信，现金，银行卡等等
-
提供给用户的是上下文类，以及各子类，创建上下文类，实例化的参数是具体的算法实例
-
缺点是用户必须提前知道所有的策略算法，而且用户需要知道上下文类，以及各子类的的区别，用户创建对象时略微麻烦（自我感觉）
-
官方解释：
动态地给给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活
-
一个职责基类或接口，一个具体操作对象类，一个装饰抽象类，多个装饰类
-
具体对象和装饰抽象都继承自基类和接口，装饰类继承自装饰抽象类
-
具体对象的实例作为参数传递给装饰类，已装饰完的类的实例继续作为参数传递给下一装饰，直到装饰完成，最后装饰完的实例调用操作方法
-
缺点
创建的对象过多，容易混杂，而且似乎好多实例用完就没用了，占用内存
-
官方解释：
为其他对象提供一种代理以控制对这个对象的访问
-
一个抽象类或接口，一个实体类，一个代理类
-
代理类和实体类都继承自抽象类或接口，代理类内部创建实体类的实例，然后实现与实体类的同一个方法的时候可以在之前或之后进行其他操作
-
看完后第一个想法是这个模式有点类似C#里的属性的概念，在某个实例被调用某个属性时，实际内部操作的是实例私有的字段，属性提供保护安全的作用，中间通过属性作为代理来操作字段（好像略微有点不恰当）
-
代理模式顾名思义就是代理的意思，和实际生活中的代理一个概念，有些商品并不由厂家直接销售，而是转交给代理商销售，代理商在销售商品时可以进行包装，打折等操作，但销售的真正的时还是厂家的商品（这么扩展的话是不是代理也可对多个对象实现代理呢，好像时动态代理的概念，再去研究一下）
-
代理分类
-
远程代理
-
虚拟代理
-
安全代理
-
智能引用代理
-
-
缺点
暂时还不清楚
-
官方解释
定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类
-
一个工厂基类，一个目标对象基类，多个具体工厂类和多个具体对象类
-
每个具体工厂类对应每个具体对象类，客户端实现是由对应工厂类去创建实例对象赋值给具体的对象
-
简单工厂违法了开放-封闭原则，而工厂方法模式则没有了这个缺点，虽然具体的判断选择哪种实例化方式移到了客户端，但是每个具体工厂可以多次使用，在需要创建很多对象的时候，工厂模式的优势就很大了，如果某一类具体对象需要变更成另一种子类，工厂模式只需要修改创建工厂时的代码，而工厂模式就需要每个都修改参数了
-
缺点
每增加一个新子类，就要相应的增加一个工厂类，增大了开发量
增加了程序的复杂性，对新人而言可读性稍微差点
-
官方解释
用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象
-
抽象原型类，具体原型类
-
抽象原型类中有一个Clone方法，这是实现原型模式的重点，在具体原型类中实现该克隆方法，返回该原型的浅复制结果，生成一个新的对象
-
原型模式有浅复制和深复制的区别，在C#中调用实例的MemberwiseClone()方法，该方法是属于浅复制，执行该方法是，如果是值类型，则按位逐一复制，如果是引用类型，则复制一份引用，所以还是同一个对象，需要注意的是string类型也是应用类型，但他同时有一些值类型的特征，所以在复制的时候也是按位复制，如果在实例中设置了引用类型，那么在设计这个被引用的类时也要赋予一个Clone方法，用来实现深复制
-
C#中原型模式太常见了，所以在System命名空间里已经提供了一个ICloneable接口，接口只有一个Clone方法，继承实现即可
-
原型模式可以理解为备份文件的过程，在备份的时候，是把当前所有的信息都复制一份，然后操作新文件不会影响原来的旧文件，这样在需要创建多个相同结果的不同对象时可以有很大用处，这样创建的过程和直接new一个对象相比，少了执行构造方法的过程，以及各属性的初始化
-
一个生活实例是生产不同用途的机器人，首先制造出一同通用机器人模板，调好参数，接下来按照这个模板制造出多个机器人，然后再对每个机器人进行不同的个性化定制
-
缺点
在设计类的时候，就要考虑到所有引用的类，这样被引用的也必须实现Clone方法，如果被引用的类是以及存在早就设计好的，则需要更改代码（这违反了开放-封闭原则），或者是重新继承添加Clone方法（增加代码量，以及容易混淆各个类）
在实现深克隆的时候可能需要比较复杂的代码
-
官方解释
定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重新定义该算法的某些特定步骤
-
当我们要完成在某一细节层次一致的一个过程或者一系列步骤，但其个别步骤在更详细的层次上实现可能不同是，通常考虑用模板方法模式来处理
-
模板方法可以说是把不变的行为搬到超类，去除子类中的重复代码来体现它的优势
-
形象的比喻就是制作汉堡，各种汉堡的制作过程都大体相同，但在某些细节方面可能不同，这就类似是想定义好了制作汉堡的过程，在要添加不同材料的地方抽象出来，推出一种新汉堡，就是重写这俄格添加材料的过程，这样类似模板方法
-
缺点
抽象类定义了部分抽象方法，这些抽象的方法由子类来实现，子类执行的结果影响了父类的结果(子类对父类产生了影响)，会带来阅读代码的难度！
