目录:html
返回顶部git
由于在学习过程当中老是不断忘记,不少东西也是只知其一;不知其二,因此学一点就又倒回来再复习一次,第一次学习的时候我主要以实现书中的代码为主,而如今复习的时候我就以弄清楚逻辑为主了,毕竟第一次基本都是只要能实现功能就大吉大利了。因此此次小阶段的复习,我就没有再在文章中写代码了,以画UML图为主,边弄清楚逻辑,边搞懂那些知识点。github
复习果真是温故而知新,确实了解到了以前比较迷茫的点,可是仍是有不少不明确之处,我以为应该还须要等把设计模式所有学完一次后再从新倒过来再看一次,可能会有其余收获吧。虽然文中全是UML图,可是全部的例子,在最后个人github中都已经上传了源代码,欢迎指教(#^.^#)。算法
ppps:在复习的过程我记录下来整理成博客来分享,可是我以为我仍是说的不是很清楚,只是本身能靠着UML图和实例能大概了解到本身须要了解的知识点,可是介绍出来总是感受哪里欠缺,我确实须要好好学习一下,怎么正确表述个人观点了。固然,这也是须要坚持写博客的缘由了ヾ(◍°∇°◍)ノ゙,要是个人表述让您没法理解,请不吝赐教,让我慢慢了解到应该怎么和别人交谈。数据库
返回顶部设计模式
策略模式定义了算法族,分别封装起来,让它们之间能够相互替换,此模式让算法的变化独立于使用算法的客户。安全
策略模式的主要组成部分主要包括Context/Strategy这两个部分。函数
策略类定义了全部支持的算法的公共接口。post
其实StrategyPattern就是将代码尽可能的变小,各部分功能尽可能单一化,将类似的功能放进同一个函数或者接口里,这个函数或者接口也就是ConcreteStrategyABC了。学习
详细解释:C#学习笔记-策略模式
这里将优惠的方式分为三种,1:正常收费;2:折扣;3.满减活动;题目中所提到的优惠方式不外乎这三种,因此将优惠方式作成一个接口CashSuper,而后往下再分支成三种具体的优惠方式,这样咱们要是某一种优惠方式有变更,直接去具体的那种优惠方式中修改便可,同时,要是添加了新的优惠方式,直接继承CashSuper这个接口,而后添加新的实现方式就行了,这样保证了原来代码的安全,也添加了新的功能。这也是咱们的设计原则:封装变化
。
咱们设计一些鸭子,这些鸭子有:绿头鸭、红头鸭、橡皮鸭、诱饵鸭等,他们有各自的外貌特征,同时有各自不一样的叫声,有的鸭子例如绿头鸭能够飞行,可是橡皮鸭这些却不能飞行。请设计出这些鸭子。
鸭子的外貌能够设定为属性,可是叫声和飞行就是两种动做,且有不一样种状况:飞行FlyBehavior有两种(FlyWithWings/FlyNoWay两种具体的不一样的实现行为),叫声QuackBehavior有不少种状况(例如:Quack/Squeak/MuteQuack),因此咱们将飞行行为和叫声这两种行为封装起来,这样保证了不一样的鸭子调用本身不一样的行为便可,同时保证了若是添加了新的鸭子又有新的行为时,方便添加新的具体的行为进来。
好的代码就是让代码变得易维护,而这就是策略模式最大的优势。
观察者模式定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时,会通知全部的观察者对象,使他们可以自动更新本身。
观察者模式重要的是Subject/Observer这两个接口。
Subject:他把全部对观察者对象的引用保存在一个汇集里,每一个主题均可以有任何数量的观察者。抽象主题提供了一个接口,能够删除和增长观察者对象。
Observer:抽象观察者,为全部的具体观察者定义一个接口,在获得主题的通知时更新本身。
抽象模式有两个方面,其中一我的方面依赖于另外一个方面,这时用观察者模式能够将这二者封装在独立的对象中使它们各自独立的改变和复用。
详细解释:C#学习笔记-观察者模式
对于具体的Observer而言(也就是MemberOne和MemberTwo),具体的Subject是谁,他们并不须要知道,只要做为Subject的那我的将有用的信息传递给他们就行了。同理,做为具体的Subject而言,不须要知道每个Observer是谁,只须要在信息更新的时候,将有用的信息传递给在他那注册了的成员就行了。这就实现了软件设计的一个重要原则:为交互对象之间的松耦合设计而努力。
如今须要创建气象观测站的一个应用:目前有三种布告板,分别显示目前的情况、气象统计即简单的预报。当WeatherObject对象得到最新的测量数据时,三种布告板必须实时更新。
这个题目很明显符合了OberverPattern要求,三个布告板理所固然地就是具体的Observer了,获取各类信息的WeatherData就是具体的Subject了。
松耦合设计更加有弹性,更能应对变化。
装饰模式,动态地给一个对象添加一些额外的职责。
不论是ConcreteComponent仍是Decorator,亦或是ConcreteDecoratorABC,他们都继承来自于Component,因此全部的一切都至关因而对Component功能的扩展,这也就是装饰模式的意义。
详细解释:C#学习笔记-装饰模式
只须要注意一点:服饰做为装饰品,须要专门记住他须要装饰的对象,否则装饰就没有任何意义了。
咱们如今来作饮料,每一种饮料有不一样的配料,每一种配料价格不同,名字不同,例如:如今顾客想要一杯加了奶泡和摩卡的深烘焙,咱们须要获得各类搭配的饮料的价格。
首先具体的饮料例如上面说的“深烘焙”在这里就是具体的Component了,那些奶泡或者摩卡都是为了修饰他而存在的,因此同理,奶泡和摩卡之类就是ConcereteDecoratorABC了。仍然要注意的是奶泡那些不准携带他们须要修饰的对象Beverage,不用指定具体修饰的哪种Beverage,可是必须有须要修饰的对象。
好的代码是对扩展开放,对修改关闭。
工厂模式,定义一个用于建立对象的接口,让子类决定实例化哪个类。
须要注意的是:工厂方法必需要返回一个Product类型的对象,由于工厂方法的惟一的做用就是实例化一个Product。
写一个简单的计算机。
将计算中的加减乘除分为四个类,这样能够相互不干扰,可是都继承于计算这个类,而后创建OperationFactory来经过用户传输进来的符号来判断到底咱们须要调用那种计算方式,也就是实例化哪种类。
详细解释:C#学习笔记-工厂模式
咱们如今开披萨连锁店,在纽约、芝加哥和加州开披萨连锁店,不一样的地区根据当地人的口味设计不一样味道的同披萨。
如今做为客人的咱们要选择披萨的时候,店家首先须要根据咱们的选择来肯定是哪一个地区的哪一种风味的披萨,因此这个时候须要实例化的就是根据选择的披萨来实例化该地区的那种风味的披萨。
设计原则:依赖抽象,不要依赖具体类。
抽象工厂模式提供一个接口,用于建立相关或依赖对象的家族,而不须要明确指出具体类。
抽象工厂模式与工厂模式的区别在于,工厂模式只是建立一个产品,而抽象工厂模式是建立产品家族,并让制造的产品集合起来使用。
因此抽象工厂模式须要一个大的接口AbstractFactory,而他具体的实现ConcreteFactory12345里面的具体实例化能够调用工厂模式。
解析:
这里的数据库不定,表单数不定,可是彼此之间均可能存在关系,因此能够调用抽象工厂模式将这一系列的产品想关联起来。
具体实现:C#学习笔记-抽象工厂模式
如今咱们创建一个工厂来生产原料;这个工厂将负责建立原料家族中的每一种原料,为披萨店提供原材料
咱们订购了pizza后,商店本身根据当前订购的pizza得到当前须要在哪家店订购披萨,而后当地的pizza在从当地的原料工厂得到制做pizza 的原料,如此来制做披萨。
这里的原料家族生成各类各样的产品,再经过不一样的组合组成,组成咱们所须要的披萨,因此这个部分咱们须要调用抽象工厂模式。
抽象工厂模式建立产品家族,工厂模式建立一个产品。
温故而知新
成长就是不断发现之前的本身是个傻逼
备注:源代码示例My Github