随笔分类 - 设计模式
摘要：本文给出了经典的23种设计模式的名录,包括他们的分类、名称、定义以及简要说明，方便大家能够快速的回忆起他们。也是前面写过的或者后面将要写的设计模式的一个目录。更是为了能督促自己能将这一个系列能坚持写完. 一.创建型 这个部分的主要任务就是使用各种方法创建(或组合)各种类型的对象,并向对象的使用者隐藏
阅读全文
摘要：大家先看下下面这段代码有什么感受?using System;using System.Collections.Generic;using System.Linq;using System.Text;using System.Windows;using System.ServiceModel;using PCI_ClassLibrary;using System.Windows.Threading;using Oland.HIP.Common.Entities;using Oland.HSS.Common;using Oland.HIP.Common.Enums;using System.W..
阅读全文
摘要：概念: 装饰者模式(Decorator Pattern): 动态地将功能添加到对象,相比生成子类更灵活,更富有弹性. 解决方案: 装饰者模式的重点是对象的类型,装饰者对象必须有着相同的接口,也也就是有着相同的结构.这样一来,在运行的过程中,就可以将这些对象融合在一起,将相同的属性等成员有机的结合,就像生成另外一种类型一样,而实际上,我们并不需要真的创建这个类型,它是动态生成的.这些装饰者既可以组合,也可以撤销组合,既回复到原来对象状态. 示例介绍: 装饰者模式的关键就是装饰者类型的定义,而其中应包括组合操作的方法. 现在我们看一下装饰者接口的定义: ...
阅读全文
摘要：一、ISP简介（ISP--Interface Segregation Principle）：使用多个专门的接口比使用单一的总接口要好。一个类对另外一个类的依赖性应当是建立在最小的接口上的。一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。“不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。”这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。二、举例说明：参考下图的设计，在这个设计里，取款
阅读全文
摘要：一、LSP简介（LSP--Liskov Substitution Principle）：定义：如果对于类型S的每一个对象o1，都有一个类型T的对象o2，使对于任意用类型T定义的程序P，将o2替换为o1，P的行为保持不变，则称S为T的一个子类型。子类型必须能够替换它的基类型。LSP又称里氏替换原则。对于这个原则，通俗一些的理解就是，父类的方法都要在子类中实现或者重写。二、举例说明：对于依赖倒置原则，说的是父类不能依赖子类，它们都要依赖抽象类。这种依赖是我们实现代码扩展和运行期内绑定（多态）的基础。因为一旦类的使用者依赖某个具体的类，那么对该依赖的扩展就无从谈起；而依赖某个抽象类，则只要实现了该抽
阅读全文
摘要：一、DIP简介（DIP--Dependency InversionPrinciple）：1、高层模块不应该依赖于低层模块,二者都应该依赖于抽象。2、抽象不应该依赖于细节,细节应该依赖于抽象。高层模块包含了一个应该程序中的重要的策略选择和业务模型，正是这些高层模块才使得其所有的应用程序区别于其他，如果高层依赖于低层,那么对低层模块的改动就会直接影响到高层模块,从而迫使它们依次做出改动。二、举例说明：反面例子：缺点：耦合太紧密，Light发生变化将影响ToggleSwitch。解决办法一：将Light作成Abstract，然后具体类继承自Light。优点：ToggleSwitch依赖于抽象类Lig
阅读全文
摘要：一、OCP简介（OCP--Open-Closed Principle）：Software entities(classes,modules,functions,etc.) should be open for extension, but closed for modification。软件实体应当对扩展开放，对修改关闭，即软件实体应当在不修改（在.Net当中可能通过代理模式来达到这个目的）的前提下扩展。Open for extension:当新需求出现的时候，可以通过扩展现有模型达到目的。 Close for modification:对已有的二进制代码，如dll,jar等，则不允许做任..
阅读全文
摘要：一、SRP简介（SRP--Single-Responsibility Principle）：就一个类而言，应该只专注于做一件事和仅有一个引起它变化的原因。所谓职责，我们可以理解他为功能，就是设计的这个类功能应该只有一个，而不是两个或更多。也可以理解为引用变化的原因，当你发现有两个变化会要求我们修改这个类，那么你就要考虑撤分这个类了。因为职责是变化的一个轴线，当需求变化时，该变化会反映类的职责的变化。“就像一个人身兼数职，而这些事情相互关联不大，，甚至有冲突，那他就无法很好的解决这些职责，应该分到不同的人身上去做才对。”二、举例说明：违反SRP原则代码:modem接口明显具有两个职责：连接管理和
阅读全文
摘要：这几天重新看了一遍《大话设计模式》，发现果然有不同的感悟，而且自己也上网找了《敏捷软件开发—原则、模式与实践》一书来看，那本书的序言中有一段话我觉得很有道理：“美的东西比丑的东西创建起来更廉价，也更快捷。”设计一个软件不关要追求代码的优雅问题，更关乎生产成本等。技术大师们在对软件架构的研究中经历了很长时间的摸索，从面向过程到面向对象，从设计原则到设计模式，总结了许多设计上的经典法则，而我们就只是站在巨人的肩膀上眺望远方而已。 从《大话设计模式》中，大家一定会发现其中的经典的23个模式背后，其实都遵循着一些基本的原则的。而设计原则又由设计模式来实现，这就是二者相辅相成的关系，所以了解原则对于了.
阅读全文