转载于：http://blog.csdn.net/zhengzhb/article/details/7281833        肯定有不少人跟我刚看到这项原则的时候一样，对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的。 定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1

转载于：http://blog.csdn.net/zhengzhb/article/details/7289269 定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。 问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改

设计模式总览 单一职责原则，顾名思义，就是一个类只有一个职责。那么这个职责到底是什么意思呢？它可以被理解为“引起变化的原因”。如果一个类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响复用性。 什么叫“引起变化的原因”？举个例子：有三只猫：白猫、黑猫、花猫。如果以编程的角度来看，是不是就要有三个类，白猫类，黑

设计模式总览 依赖倒置原则（Dependence Inversion Principle） 该原则规定： ①高层模块不依赖低层模块。两者都应该依赖抽象接口 ②抽象不能依赖具体。而具体应该依赖抽象接口 此原则的目的是为了实现解耦。将依赖关系建立在高层，而低层用来做具体实现。因为高层相对稳定，不会经常变动，而具体实现则会经常变动。 其实该原则，在现实生活中也经常用到。以电脑cpu来说，主板厂商定好cp

设计模式总览 里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现；并且完全察觉不出父类对象和子类对象的区别。 里氏代换原则是一个规范性原则，它是继承复用的基石。只有按照这个规范来具体化抽象，才能保证这个系统正常运行！ 代码定义： // 如果D派生自B；B、D指向同一对象；则tes

周末出去参加了一趟婚礼，趁着酒店休息时间以及路上时间，抽空看了下《设计模式之禅》这本书，讲解还是相当到位的，让我这种小白也能初窥大概，趁机做了下笔记。在之后几篇文章中应该都能体现出来。     嗯 顺便说一下：kindle 真是个好东西，拿着趁手，晚上座公交车，司机不开灯也能看。而且看书随时随地，大赞大赞。大部头的书终于不用放进书包了！！！     进入正题： 六大设计原则： Single Res

先讲下继承： 优点：         代码共享，代码重用，可扩展，开放性 缺点：         侵入性，降低灵活性，增强耦合性 解决继承的缺点： 里氏替换！ 定义1：If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T,

定义：High Level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details.Details should depend upon abstractions. 定义的含义：     a.

1.单一职责原则，（Single Responsibility Principle）. 定义：There should never be more than one reason for a class to change，应该有且仅有一个原因引起类的变更。 职责：业务逻辑，或者对象能够承担的责任，并以某种行为方式来执行。 2.理解 该原则提出了对对象职责的一种理想期望。对象不应该承担太多职责，正

1. 里氏替代原则，(Liskov Substitution Principle, LSP ) 定义：Functions that use pointers or referrnces to base classes must be able to use objects of derived classes without knowing it.(所有引用基类的地方必须能透明地使用其子类的对象。

1. 依赖倒置原则，(Dependence Inversion Principle, DIP ) 定义：High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Deta

一、简介        在UML类图中，类之间的关系可以分成：关联(association)、聚合(aggregation)、组合(composition)、依赖(dependency)、泛化(generalization)/继承(inheritance)和实现(realization)。这六种关系如下图所描绘：               上面的关系可以解读如下: (关联)Association

 定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。 问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。 解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，

 肯定有不少人跟我刚看到这项原则的时候一样，对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的。 定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子

 定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。 问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。 解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间

      定义       就一个类而言，应该仅有一个引起它变化的原因。通俗的说，一个类只负责一项职责。       问题的由来       手机的功能多，但是每一项的功能都不强：       拍摄功能——>专业的摄像机和照相机       手机游戏——>PSP       网络摄像头——>专业摄像头       GPS功能——>专业GPS导航系统       每一个职责都是一个变化的轴线，当需

    定义    依赖倒置原则（Dependency Inversion Principle）     核心思想：依赖于抽象     具体体现：         体现一：高层模块不应该依赖低层模块。两个都应该依赖抽象。         体现二：抽象不应该依赖细节。细节应该依赖抽象。     依赖倒置原则告诉我们：细节是多变的，而抽象是相对稳定的。所以我们编程的时候要注重抽象的编程，而非细节编程。

一：单一职责原则（SRP），就一个类而言，应该仅有一个引起它变化的原因。一个类，只有一个引起它变化的原因。应该只有一个职责。每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响复用性。例如：要实现逻辑和界面的分离。 二：如果一个类承担的职责过多，就等于把这些职责耦合在一起，

1.依赖倒转原则：抽象不应该依赖细节，细节应该依赖于抽象。就是要针对接口来编程，不要对实现编程。组装机过程中，CPU，内存，硬盘都是在针对接口设计的，如果针对实现来设计，那就会出现换内存需要把主板也换了的尴尬。 2.高层模块不应该依赖底层模块。两个都应该依赖抽象。 3.里氏代换原则：子类型必须能够替换掉他们的父类型。子类继承了父类，那么子类可以以父类的形式出现。 4.在编程世界里，企鹅不能以父类-

       概述        里氏替换原则（LSP，Liskov Substitution Principle）是关于继承机制的原则，是实现开放封闭原则的具体规范，违反了里氏替换原则必然违反了开放封闭原则。        引经据典                        约瑟夫.斯大林，苏联时期苏联共产党的最高领导人，对于斯大林有没有替身？有几个替身？有一种说法：斯大林有好几个替身，最著