01 2016 档案

摘要:使用反射、特性简化代码 参考项目:利用反射验证Model类/AssemblyVerification 假设现在有一个学生类(Student) /// <summary> /// 学生类 /// </summary> public class Student { /// <summary> /// 名 阅读全文
posted @ 2016-01-29 16:01 无心々菜 阅读(245) 评论(0) 推荐(0) 编辑
摘要:21.策略模式(Strategy Pattern) 阅读全文
posted @ 2016-01-28 17:40 无心々菜 阅读(97) 评论(0) 推荐(0) 编辑
摘要:22.访问者模式(Visitor Pattern) 阅读全文
posted @ 2016-01-28 17:40 无心々菜 阅读(77) 评论(0) 推荐(0) 编辑
摘要:23.状态模式(State Pattern) 阅读全文
posted @ 2016-01-28 17:40 无心々菜 阅读(104) 评论(0) 推荐(0) 编辑
摘要:20.备忘录模式(Memento Pattern) 阅读全文
posted @ 2016-01-28 17:39 无心々菜 阅读(114) 评论(0) 推荐(0) 编辑
摘要:18.中介者模式(Mediator Pattern) 阅读全文
posted @ 2016-01-28 17:38 无心々菜 阅读(110) 评论(0) 推荐(0) 编辑
摘要:19.职责链模式(Chain of Responsibility Pattern) 阅读全文
posted @ 2016-01-28 17:38 无心々菜 阅读(93) 评论(0) 推荐(0) 编辑
摘要:动机(Motivate): 在软件构建 过程中,我们需要为某些对象建立一种“通知依赖关系” 一个对象(目标对象)的状态发生改变,所有的依赖对象(观察者对象)都将得到通知。如果这样的依赖关系过于紧密,将使软件不能很好地抵御变化。使用面 向对象技术,可以将这种依赖关系弱化,并形成一种稳定的依赖关系。从而 阅读全文
posted @ 2016-01-28 17:37 无心々菜 阅读(246) 评论(0) 推荐(0) 编辑
摘要:17.解释器模式(Interpreter Pattern) 阅读全文
posted @ 2016-01-28 17:37 无心々菜 阅读(84) 评论(0) 推荐(0) 编辑
摘要:动机(Motivate): 在软件构建过程中,集合对象内部结构常常变化各异。但对于这些集合对象,我们希望在不暴露其内部结构的同时,可以让外部客户代码透明地访问其中包含的元素;同时这种“透明遍历”也为“ 同一种算法在多种集合对象上进行操作”提供了可能。 使用面向对象技术将这种遍历机制抽象为“迭代器对象 阅读全文
posted @ 2016-01-27 16:40 无心々菜 阅读(174) 评论(0) 推荐(0) 编辑
摘要:耦合与变化: 耦合是软件不能抵御变化灾难的根本性原因。不仅实体对象与实体对象之间存在耦合关系,实体对象与行为操作之间也存在耦合关系。 动机(Motivate): 在软件系统中,“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合,比如要对行为进行“记录、撤销/重做、事务”等处理,这种无 阅读全文
posted @ 2016-01-27 16:39 无心々菜 阅读(142) 评论(0) 推荐(0) 编辑
摘要:直接与间接: 人们对复杂的软件系统常有一种处理手法,即增加一层间接层,从而对系统获得一种更为灵活、满足特定需求的解决方案。 动机(Motivate): 在面向对象系统中,有些对象由于某种原因(比如对象创建的开销很大,或者某些操作需要安全控制,或者需要进程外的访问等),直接访问会给使用者、或者系统结构 阅读全文
posted @ 2016-01-27 16:38 无心々菜 阅读(146) 评论(0) 推荐(0) 编辑
摘要:无处不在的Template Method 如果你只想掌握一种设计模式,那么它就是Template Method!动机(Motivate): 变化 -----是软件设计的永恒主题,如何管理变化带来的复杂性?设计模式的艺术性和复杂度就在于如何分析,并发现系统中的变化和稳定点,并使用特定的设计方法来应对这 阅读全文
posted @ 2016-01-27 16:38 无心々菜 阅读(345) 评论(0) 推荐(0) 编辑
摘要:面向对象的代价 面向对象很好地解决了系统抽象性的问题,同时在大多数情况下,也不会损及系统的性能。但是,在某些特殊的应用中下,由于对象的数量太大,采用面向对象会给系统带来难以承受的内存开销。比如:图形应用中的图元等对象、字处理应用中的字符对象等。 动机(Motivate): 采用纯粹对象方案的问题在于 阅读全文
posted @ 2016-01-27 16:03 无心々菜 阅读(165) 评论(0) 推荐(0) 编辑
摘要:动机(Motivate): 在软件开发系统中,客户程序经常会与复杂系统的内部子系统之间产生耦合,而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口?如何将复杂系统的内部子系统与客户程序之间的依赖解耦?意图(Intent): 为子系统中的一组接口提供一个一致的界面,Fac 阅读全文
posted @ 2016-01-27 11:55 无心々菜 阅读(194) 评论(0) 推荐(0) 编辑
摘要:动机(Motivate): 组合模式有时候又叫做部分-整体模式,它使我们树型结构的问题中,模糊了简单元素和复杂元素的概念,客户程序可以向处理简单元素一样来处理复杂元素,从而使得客户程序与复杂元素的内部结构解耦。意图(Intent):将对象组合成树形结构以表示“部分-整体”的层次结构。Composit... 阅读全文
posted @ 2016-01-25 14:25 无心々菜 阅读(189) 评论(0) 推荐(0) 编辑
摘要:子类复子类,子类何其多 假如我们需要为游戏中开发一种坦克,除了各种不同型号的坦克外,我们还希望在不同场合中为其增加以下一种或多种功能;比如红外线夜视功能,比如水陆两栖功能,比如卫星定位功能等等。按类继承的作法如下://抽象坦克 public abstract class Tangk { ... 阅读全文
posted @ 2016-01-22 14:15 无心々菜 阅读(239) 评论(0) 推荐(0) 编辑
摘要:动机(Motivate):在软件系统中,某些类型由于自身的逻辑,它具有两个或多个维度的变化,那么如何应对这种“多维度的变化”?如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化,而又不引入额外的复杂度?意图(Intent):将抽象部分与实现部分分离,使它们都可以独立的变化。 ... 阅读全文
posted @ 2016-01-22 10:49 无心々菜 阅读(191) 评论(0) 推荐(0) 编辑
摘要:适配(转换)的概念无处不在......适配,即在不改变原有实现的基础上,将原先不兼容的接口转换为兼容的接口。例如:二转换为三箱插头,将高电压转换为低电压等。动机(Motivate): 在软件系统中,由于应用环境的变化,常常需要将“一些现存的对象”放在新的环境中应用,但是新环境要求的接口是这些现存对象... 阅读全文
posted @ 2016-01-22 10:07 无心々菜 阅读(181) 评论(0) 推荐(0) 编辑
摘要:依赖关系倒置: 动机(Motivate): 在软件系统中,经常面临着“某些结构复杂的对象”的创建工作;由于需求的变化,这些对象经常面临着剧烈的变化,但是它们却拥有比较稳定一致的接口。 如何应对这种变化?如何向“客户程序(使用这些对象的程序)"隔离出“这些易变对象”,从而使得“依赖这些易变对象的... 阅读全文
posted @ 2016-01-21 17:44 无心々菜 阅读(141) 评论(0) 推荐(0) 编辑
摘要:耦合关系: 动机(Motivation): 在软件系统中,由于需求的变化,"这个对象的具体实现"经常面临着剧烈的变化,但它却有比较稳定的接口。 如何应对这种变化呢?提供一种封装机制来隔离出"这个易变对象"的变化,从而保持系统中"其它依赖的对象"不随需求的变化而变化。意图(Intent): 定义一个用... 阅读全文
posted @ 2016-01-21 14:45 无心々菜 阅读(159) 评论(0) 推荐(0) 编辑
摘要:Builder模式的缘起: 假设创建游戏中的一个房屋House设施,该房屋的构建由几部分组成,且各个部分富于变化。如果使用最直观的设计方法,每一个房屋部分的变化,都将导致房屋构建的重新修正.....动机(Motivation): 在软件系统中,有时候面临一个"复杂对象"的创建工作,其通常由各个部分的... 阅读全文
posted @ 2016-01-20 14:31 无心々菜 阅读(173) 评论(0) 推荐(0) 编辑
摘要:常规的对象创建方法://创建一个Road对象Road road =new Road();new 的问题: 实现依赖,不能应对“具体实例化类型”的变化。解决思路: 封装变化点-----哪里变化,封装哪里 潜台词: 如果没有变化,当然不需要额外的封装!工厂模式的缘起 变化点在“对象创建”,因此就封装“对... 阅读全文
posted @ 2016-01-20 11:58 无心々菜 阅读(214) 评论(0) 推荐(0) 编辑
摘要:创建型模式---单件模式(Singleton Pattern)动机(Motivation): 在软件系统中,经常有这样一些特殊的类,必须保证它们在系统中只存在一个实例,才能确保它们的逻辑正确性、以及良好的效率。 如何绕过常规的构造器,提供一种机制来保证一个类只创建一个实例? 这应该是类设计者的责任,... 阅读全文
posted @ 2016-01-20 11:54 无心々菜 阅读(152) 评论(0) 推荐(0) 编辑
摘要:创建型: 1.单件模式(Singleton Pattern) 2.抽象工厂(Abstract Factory) 3.建造者模式(Builder) 4.工厂方法模式(Factory Method) 5.原型模式(Prototype) 结构型: 6.适配器模式(Adapter Pattern) 7.桥接 阅读全文
posted @ 2016-01-20 11:01 无心々菜 阅读(264) 评论(0) 推荐(0) 编辑

点击右上角即可分享
微信分享提示