设计模式
文章平均质量分 51
wangzhaoo
风继续吹
展开
-
单一职责原则(SRP)
单一职责原则:就一个类而言,应该仅有一个引起它变化的原因。 什么是职责?在SRP中,我们把职责定义为“变化的原因”。如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责。 每个职责都是变化的一个轴线。当需求变化的时候,这种变化会反映为类的职责的变化。如果一个类承担的职责过多,就等于把这些职责耦合在一起,而一个职责的变化可能会削弱甚至是抑制这个类完成其他职责的原创 2012-08-18 09:46:58 · 406 阅读 · 0 评论 -
Liskov替换原则(LSP)
Liskov替换原则(LSP): 子类型必须能够替换他们的基类。 我们来看一个以微妙的方式违反LSP的例子:正方形是长方形的子类么? class Rectangle { public: void Square::SetWidth (double w) { Rectangle::SetWidth (w); } 假设这个应用程序运行得很好,并被安装在很多地方。但是原创 2012-08-30 11:22:16 · 589 阅读 · 0 评论 -
开放-封闭原则(OCP)
开放-封闭原则(OCP): 软件实体(类、模块、函数等等)应该是可以扩展的,但是不可以修改。 遵循OCP原则设计的模块具有两个主要的特征。它们是: 1.对于扩展是开放的。这意味着模块的行为是可以扩展的。当应用的需求改变时,我们可以对模块进行扩展,使得其具有满足那些改变的新行为。也就是说,我们可以改变模块的功能。 2.对于更改是封闭的。这意味着我们在对模块行为进行扩展时,不必改动模块原创 2012-08-24 10:12:28 · 510 阅读 · 0 评论 -
依赖倒置原则(DIP)
依赖倒置原则(DIP) a.高层模块不应该依赖于底层模块。二者都应该依赖于抽象。 b.抽象不应该依赖于细节。细节应该依赖于抽象。 使用传统的过程化程序设计所创建出来的依赖关系结构,策略是依赖于细节的。这是糟糕的,因为这样会是策略受到细节改变的影响。面向对象的程序设计倒置了依赖关系结 构,使得细节和策略都依赖于抽象,并且常常是客户拥有服务接口。 请考虑一下当高层模块依赖于低层模块是原创 2012-09-05 09:41:31 · 450 阅读 · 0 评论 -
从今天开始全面学习设计模式...坚持就是胜利
摘抄一段对模式描述得比较到位的文档。 ------------------------------------------------------------------ 一个围棋下得好的人知道,好的“形”对于围棋非常重要。形是旗子在棋盘上的几何形状的抽象化。 形就是模式(pattern),也是人脑把握和认识外界的关键。人脑处理模式的能力也非常高超,人可以在几百张面孔中一下子辨认出所熟悉的脸原创 2012-08-14 10:03:40 · 515 阅读 · 1 评论 -
接口隔离原则(ISP)
接口隔离原则(ISP) 不应该强迫客户依赖于它们不用的方法 如果强迫客户程序依赖于那些它们不使用的方法,那么这些客户程序就面临着由于这些未使用方法的改变所带来的变更。这无意中导致了所有客户程序却要使用该方法,那么 当其他客户要求这个类改变时,就会影响到这个客户程序。我们希望尽可能地避免这种耦合,因此我们希望分离接口。原创 2012-09-08 09:15:31 · 339 阅读 · 0 评论 -
简单工厂模式
创建模式是对类的实例化过程的抽象化。 从设计模式的分类上来说,简单工程模式属于类的创建模式,又叫静态工厂方法。 简单工厂模式是由一个工厂对象根据传入的参量来决定创建出哪一种产品类的实例。 简略图: Creator源码: public class Creator { public static Product factory() {原创 2012-09-22 09:14:15 · 369 阅读 · 0 评论