java设计原则:16种原则
一 类的设计原则
1 依赖倒置原则-Dependency Inversion Principle (DIP)
2 里氏替换原则-Liskov Substitution Principle (LSP)
3 接口分隔原则-Interface Segregation Principle (ISP)
4 单一职责原则-Single Responsibility Principle (SRP)
5 开闭原则-The Open-Closed Principle (OCP)
二 包的设计原则
6 重用发布等价原则-Release ReuseEquivalency Principle (REP)
7 无环依赖原则-The AcyclicDependencies Principle (ADP)
8 稳定依赖原则-The StableDependencies Principle (SDP)
9 稳定抽象等价原则-The StableAbstractions Principle (SAP)
10 共同封闭原则-The CommonClosure Principle (CCP)
11 全部重用原则-The Common Reuse Principle (CRP)
三 扩展原则
12 迪米特法则 -Least Knowledge Principle (LKP)
13 黑盒原则- BBP(Black Box Principle)
14 缺省抽象原则 -DAP(Default Abstraction Principle)
15 接口设计原则 -IDP(Interface Design Principle)
16 不要构造具体的超类原则 -DCSP(Don't Concrete SupperclassPrinciple)
1. Dependency Inversion Principle (DIP) - 依赖倒置原则
依赖:在程序设计中,如果一个模块a使用或调用了另一个模块b,我们称模块a依赖模块b。 依赖倒置原则的2个重要方针: A. 高层模块不应该依赖于低层模块,二者都应该依赖于抽象 为什么叫做依赖倒置(Dependency Inversion)呢? 面向对象程序设计相对于面向过程(结构化)程序设计而言,依赖关系被倒置了。因为传统的结构化程序设计中,高层模块总是依赖于低层模块。 问题的提出:
Robert C. Martin在原文中给出了“Bad Design”的定义: 导致“Bad Design”的很大原因是“高层模块”过分依赖“低层模块”。一个良好的设计应该是系统的每一部分都是可替换的。如果“高层模块”过分依赖“低层模块”,一方面一旦“低层模块”需要替换或者修改,“高层模块”将受到影响;另一方面,高层模块很难可以重用。 比如,一个Copy模块,需要把来自Keyboard的输入复制到Print,即使对Keyboard和Print的封装已经做得非常好,但如果Copy模块里直接使用Keyboard与Print,Copy任很难被其他应用环境(比如需要输出到磁盘时)重用。 问题的解决:
为了解决上述问题,Robert C. Martin提出了OO设计的Dependency Inversion Principle (DIP) 原则。 Robert C. Martin给出的DIP方案的类的结构图: PolicyLayer-->MechanismInterface(abstract)--MechanismLayer-->UtilityInterface(abstract)--UtilityLayer 2. Liskov Substitution Principle (LSP) - 里氏替换原则
|
3. Interface Segregation Principle (ISP) - 接口分隔原则
不能强迫用户去依赖那些他们不使用的接口。换句话说,使用多个专门的接口比使用单一的总接口总要好。它包含了2层意思: 如果用户被迫依赖他们不使用的接口,当接口发生改变时,他们也不得不跟着改变。换而言之,一个用户依赖了未使用但被其他用户使用的接口,当其他用户修改该接口时,依赖该接口的所有用户都将受到影响。这显然违反了开闭原则,也不是我们所期望的。 下面我们举例说明怎么设计接口或类之间的关系,使其不违反ISP原则。 有以下几种设计方法: ISP原则的违反例: 方法一: 但这样一来,依赖Door接口的CommonDoor却不得不实现未使用的alarm()方法。违反了ISP原则。 方法二: 跟方法一一样,依赖Door接口的CommonDoor却不得不实现未使用的alarm()方法。违反了ISP原则。 遵循ISP原则的例: 方法三:通过多重继承实现 Adapter设计模式的实现。 方法四:通过委托实现 在Alarm接口定义alarm方法,在Door接口定义lock,unlock方法。接口之间无继承关系。CommonDoor实现Door接口, 小结 Interface Segregation Principle (ISP)从对接口的使用上为我们对接口抽象的颗粒度建立了判断基准:在为系统设计接口的时候,使用多个专门的接口代替单一的胖接口。 |
4. Single Responsibility Principle (SRP) - 单一职责原则
永远不要让一个类存在多个改变的理由。换句话说,如果一个类需要改变,改变它的理由永远只有一个。如果存在多个改变它的理由,就需要重新设计该类。 SRP(Single Responsibility Principle)原则的核心含意是:只能让一个类有且仅有一个职责。这也是单一职责原则的命名含义。 为什么一个类不能有多于一个以上的职责呢? 职责的划分 既然一个类不能有多个职责,那么怎么划分职责呢? Single Responsibility Principle (SRP)的原文里举了一个Modem的例子来说明怎么样进行职责的划分,这里我们也沿用这个例子来说明一下: SRP违反例: 下面的类图将它的2个不同职责分成2个不同的接口,这样至少可以让客户端应用程序使用具有单一职责的接口: 让ModemImplementation实现这两个接口。我们注意到,ModemImplementation又组合了2个职责,这不是我们希望的,但有时这又是必须的。通常由于某些原因,迫使我们不得不绑定多个职责到一个类中,但我们至少可以通过接口的分割来分离应用程序关心的概念。 小结 Single Responsibility Principle (SRP)从职责(改变理由)的侧面上为我们对类(接口)的抽象的颗粒度建立了判断基准:在为系统设计类(接口)的时候应该保证它们的单一职责性。 |
5. The Open-Closed Principle (OCP) - 开闭原则
开闭原则(OCP:Open-Closed Principle)是指在进行面向对象设计(OOD:Object Oriented Design)中,设计类或其他程序单位时,应该遵循: 这也是系统设计需要遵循开闭原则的原因: 开闭原则的实现方法 为了满足开闭原则的 对修改关闭(closed for modification) 原则以及扩展开放(open for extension) 原则,应该对软件系统中的不变的部分加以抽象,在面向对象的设计中, 接口可以被复用,但接口的实现却不一定能被复用。接口是稳定的,关闭的,但接口的实现是可变的,开放的。可以通过对接口的不同实现以及类的继承行为等为系统增加新的或改变系统原来的功能,实现软件系统的柔软扩展。 简单地说,软件系统是否有良好的接口(抽象)设计是判断软件系统是否满足开闭原则的一种重要的判断基准。现在多把开闭原则等同于面向接口的软件设计。 开闭原则的相对性 软件系统的构建是一个需要不断重构的过程,在这个过程中,模块的功能抽象,模块与模块间的关系,都不会从一开始就非常清晰明了,所以构建100%满足开闭原则的软件系统是相当困难的,这就是开闭原则的相对性。但在设计过程中,通过对模块功能的抽象(接口定义),模块之间的关系的抽象(通过接口调用),抽象与实现的分离(面向接口的程序设计)等,可以尽量接近满足开闭原则。 6. Release Reuse Equivalency Principle (REP) - 重用发布等价原则
|
7. The Acyclic Dependencies Principle (ADP) - 无环依赖原则
包之间的依赖结构必须是一个直接的无环图形(DAG)。也就是说,在依赖结构中不允许出现环(循环依赖)。换成另一个说法是: 包间依赖不能是一个环状形式。包间关系方面(耦合性)的原则 包的依赖 图1(包A依赖包B) 包的循环依赖 图2:包的循环依赖 包的非循环依赖原则 包是一个比较合适的发布粒度,当修改了包中的代码(类,模块等)并发布新的版本时,我们需要把该包以及它所依赖的其它包一起发布。发布之后,还需要验证系统是否能在新发布的版本下正常运作。 循环依赖的打破方法 如果包的依赖形成了环状结构,怎么样打破这种循环依赖呢? 方法一:创建新的包 图2:包的循环依赖 包C要依赖包A,必定A中包含有A,C共通使用的类,把这些共同类抽出来放在一个新的包D里。这样就把C依赖A变成了C依赖D以及A依赖D,从而打破了循环依赖关系。如图: 这样,包的依赖关系就从A->B->C->A变成了: 方法二:DIP与ISP设计原则 如图,,包A依赖包B(因为包A中的类U使用了包B中的类X);反过来,包B又依赖包A(因为包B中的类Y使用了包A中的类V) 包A,包B之间就形成了一种循环依赖。 我们使用DIP设计原则为V抽象一个接口IVforY,并把该接口放在B包中。 这样一来,包B中的类就不依赖任何包A中的类了。 小结 无环依赖原则(ADP)为我们解决包之间的关系耦合问题。在设计包结构时,不能有循环依赖。 |
8. The Stable Dependencies Principle (SDP) - 稳定依赖原则
一个设计中的包之间的依赖应该朝着稳定的方向进行。一个包只应该依赖那些比自己更稳定的包。换成另一个说法是: 朝着稳定的方向进行依赖。包之间的关系方面(耦合性)的原则。 包的依赖 如果一个包A 中的类引用了包B中的类,我们称包A依赖包B。 图1(包A依赖包B) 包的稳定依赖原则 包应该依赖比自己更稳定的包。因为如果依赖一个不稳定的包,那么当这个不稳定的包发生变化时,本身稳定的包也不得不发生变化,变得不稳定了。 所谓稳定,在现实生活中是指一个物体具有稳固不变的属性使它很难发生变化。应用到软件概念上,我们认为一个软件是稳定的,是因为这个软件很难发生改变,或更确切地说,是不需要发生改变。一个设计良好,能应对各种变化不需要修改的软件当然是稳定的了,但事实上,往往一个软件常常需要对应某个事先没有预测到的用户需求而不得不发生改变,当这种改变发生时,能把修改控制在最小的范围之内,并能稳定的工作(包括软件本身以及依赖它的其它软件实体等),我们也会认为该软件是相对稳定的。 怎么样让一个软件足够稳定呢?一个确切的方法是,让大量其它软件的包依赖它。一个包被很多其他包依赖是非常稳定的,这是因为被依赖的包为了协调其他包必须做很多的工作来对应各种变化(责任的负担者)。 图1:稳定的包X 相反,下面列出了一个非常不稳定的包Y,如图: 图2:不稳定的包Y 包的稳定性的判断原则 可以通过下面的方法来判断一个包的稳定系数: SDP要求一个包的不稳定性I要大于它所依赖的包的不稳定性。换句话说,沿着依赖的方向,包的不稳定性应该逐渐降低,稳定性应该逐渐升高。 稳定依赖原则(SDP)为我们解决包之间的关系耦合问题。在设计包结构时,包应该只依赖比自己更稳定的包。 |
9. The Stable AbstractionsPrinciple (SAP) - 稳定抽象等价原则
最稳定的包应该是最抽象的包。不稳定的包应该是具体的包。包的抽象程度跟它的稳定性成正比。稳定的包应该是抽象的包。 包的稳定抽象等价原则 我们在The Stable Dependencies Principle (SDP) - OO设计的稳定依赖原则 一文中谈到了包的稳定性:不容易改变的包应该具有更好的稳定性。 一个包的抽象程度越高,它的稳定性就越高。反之,它的稳定性就越低。一个稳定的包必须是抽象的,反之,不稳定的包必须是具体的。 稳定的包的构成 理想的体系结构应该是: 图1:遵循稳定依赖原则(SDP)的理想的体系结构 小结 稳定抽象等价原则(SAP)为我们解决包之间的关系耦合问题。在设计包结构时,稳定的包应该是抽象的(由抽象类或接口构成),不稳定的包应该是具体的(由具体的实现类构成)。 |
10. The Common ClosurePrinciple (CCP) - 共同封闭原则
一个包中所有的类应该对同一种类型的变化关闭。一个变化影响一个包,便影响了包中所有的类。一个更简短的说法是:一起修改的类,应该组合在一起(同一个包里)。包的内部关系方面(聚合性)的原则 如果必须修改应用程序里的代码,我们希望所有的修改都发生在一个包里(修改关闭),而不是遍布在很多包里。 CCP跟开闭原则(OCP: Open Closed Principle) 有着很深的渊源关系,CCP的“关闭”(closure)就是OCP所提倡的:classes should be closed for modification but open for extension. 类应该对修改关闭,对扩展开放。但我们知道,100%的“关闭”是不现实的,我们在设计系统时,只能尽量地保持对大多数可预见的修改关闭。 小结 共同封闭原则(CCP)从软件功能的角度上为我们规范了包设计的一个原则:在设计包时,相互之间紧密关联的类应该放在同一包里。 |
11. The Common Reuse Principle (CRP) - 全部重用原则
包的所有类被一起重用。如果你重用了其中的一个类,就重用全部。换成另一个比较浅显易懂的说法:没有被一起重用的类不应该被组合在一起。CRP原则帮助我们决定哪些类应该被放到同一个包里。包的内部关系方面(聚合性)的原则 依赖一个包就是依赖这个包所包含的一切。当一个包发生了改变,并发布新的版本,使用这个包的所有用户都必须在新的包环境下验证他们的工作,即使被他们使用的部分没有发生任何改变。 “不能强迫用户去依赖那些他们不使用的接口”,把这个概念应用到更广范围的包上,就是CRP的基本理念:不要把用户不使用的类一起组合进包里。 CRP与REP一样,都是从方便用户重用的角度去设计包,重用者是他们的受益者,CCP则让系统的维护者受益。CCP让包尽可能大(CCP原则加入功能相关的类),CRP则让包尽可能小(CRP原则剔除不使用的类)。它们的出发点不一样,但不相互冲突。CRP保证了包的内部具有很高的聚合性。 全部重用原则(CRP)从用户的角度上为我们规范了包设计的一个原则:在设计包时,相互之间没有紧密关联的类不应该放在同一包里。 12. Least Knowledge Principle (LKP) -迪米特法则 迪米特法则(Law of Demeter,LoD)也称为最少知识原则(Least Knowledge Principle,LKP)。 一个对象应该对其他对象有最少的了解。通俗地讲,一个类应该对自己需要耦合或调用的类知道得最少,你(被耦合或调用的类)的内部是如何复杂都和我没关系,那是你的事情,我就知道你提供的public方法,我就调用这么多,其他的一概不关心。 含义:
朋友类的定义是这样的:出现在成员变量、方法的输入输出参数中的类称为成员朋友类,而出现在方法体内部的类不属于朋友类。下面的代码在方法体内部依赖了其他类,这严重违反迪米特法则
方法是类的一个行为,类竟然不知道自己的行为与其他类产生了依赖关系,这是不允许的。 正确的做法是:
注意:一个类只和朋友交流,不与陌生类交流,不要出现getA().getB().getC().getD()这种情况(在一种极端情况下允许出现这种访问,即每一个点号后面的返回类型都相同),类与类之间的关系是建立在类间的,而不是方法间,因此一个方法尽量不引入一个类中不存在的对象,当然,JDK API提供的类除外。
一个类公开的public属性或方法越多,修改时涉及的面也就越大,变更引起的风险扩散也就越大。因此,为了保持朋友类间的距离,在设计时需要反复衡量:是否还可以再减少public方法和属性,是否可以修改为private、package-private(包类型,在类、方法、变量前不加访问权限,则默认为包类型)、protected等访问权限,是否可以加上final关键字等。 注意:迪米特法则要求类“羞涩”一点,尽量不要对外公布太多的public方法和非静态的public变量,尽量内敛,多使用private、package-private、protected等访问权限。
如果一个方法放在本类中,既不增加类间关系,也对本类不产生负面影响,就放置在本类中。
最后,迪米特法则的核心观念就是类间解耦,弱耦合,只有弱耦合了以后,类的复用率才可以提高。 |
Principle –纵览
----类原则 ----
1.单一职责原则 -Single Responsibility Principle(SRP)
就一个类而言,应该仅有一个引起它变化的原因。
(职责即为“变化的原因”。)
2.开放-封闭原则 - OpenClose Principle(OCP)
软件实体(类、模块、函数等)应该是可以扩展的,但是不可修改。
(对于扩展是开放的,对于更改是封闭的.
关键是抽象.将一个功能的通用部分和实现细节部分清晰的分离开来.
开发人员应该仅仅对程序中呈现出频繁变化的那些部分作出抽象.
拒绝不成熟的抽象和抽象本身一样重要. )
3.里氏替换原则 -Liskov Substitution Principle(LSP)
子类型(subclass)必须能够替换掉它们的基类型(superclass)。
4.依赖倒置原则(IoCP) 或 依赖注入原则 -Dependence Inversion Principle(DIP)
抽象不应该依赖于细节。细节应该依赖于抽象。
(Hollywood原则: "Don't call us, we'll call you".
程序中所有的依赖关系都应该终止于抽象类和接口。
针对接口而非实现编程。
任何变量都不应该持有一个指向具体类的指针或引用。
任何类都不应该从具体类派生。
任何方法都不应该覆写他的任何基类中的已经实现了的方法。)
5.接口隔离原则(ISP)
不应该强迫客户依赖于它们不用的方法。
接口属于客户,不属于它所在的类层次结构。
(多个面向特定用户的接口胜于一个通用接口。)
----包内聚原则 ----
6.重用发布等价原则(REP)
重用的粒度就是发布的粒度。
7.共同封闭原则(CCP)
包中的所有类对于同一类性质的变化应该是共同封闭的。
一个变化若对一个包产生影响,
则将对该包中的所有类产生影响,
而对于其他的包不造成任何影响。
8.共同重用原则(CRP)
一个包中的所有类应该是共同重用的。
如果重用了包中的一个类,
那么就要重用包中的所有类。
(相互之间没有紧密联系的类不应该在同一个包中。)
----包耦合原则
9.无环依赖原则(ADP)
在包的依赖关系图中不允许存在环。
10.稳定依赖原则(SDP)
朝着稳定的方向进行依赖。
应该把封装系统高层设计的软件(比如抽象类)放进稳定的包中,
不稳定的包中应该只包含那些很可能会改变的软件(比如具体类)。
11.稳定抽象原则(SAP)
包的抽象程度应该和其稳定程度一致。
(一个稳定的包应该也是抽象的,一个不稳定的包应该是抽象的. )
----其它扩展原则----
12.BBP(Black Box Principle)黑盒原则
多用类的聚合,少用类的继承。
13.DAP(Default Abstraction Principle)缺省抽象原则
在接口和实现接口的类之间引入一个抽象类,这个类实现了接口的大部分操作.
14.IDP(Interface Design Principle)接口设计原则
规划一个接口而不是实现一个接口。
15.DCSP(Don't Concrete Supperclass Principle)不要构造具体的超类原则
避免维护具体的超类。
16.迪米特法则
一个类只依赖其触手可得的类。
java设计原则:16种原则的更多相关文章
- Java面向对象16种原则
一 类的设计原则 1 依赖倒置原则-Dependency Inversion Principle (DIP) 2 里氏替换原则-Liskov Substitution Principle (L ...
- Java设计模式的7种设计原则还有很多人不知道
前言 其实没有设计模式我们也能完成开发工作.但是为什么需要设计模式呢?让你看起来很牛,没错这个算一个.让你的代码层次感分明,可读性强而且容易维护.让你像我一样有更多的摸鱼划水时间. 可能有人说我一个类 ...
- [设计模式](转)Java中的24种设计模式与7大原则
*:first-child { margin-top: 0 !important; } body > *:last-child { margin-bottom: 0 !important; } ...
- java设计模式:面向对象设计的7个原则
在软件开发中,为了提高软件系统的可维护性和可复用性,增加软件的可扩展性和灵活性,程序员要尽量根据7条原则来开发程序,从而提高软件开发效率,节约软件开发成本和维护成本. 这7条原则分别是:开闭原则.里氏 ...
- C#软件设计——小话设计模式原则之:依赖倒置原则DIP
前言:很久之前就想动笔总结下关于软件设计的一些原则,或者说是设计模式的一些原则,奈何被各种bootstrap组件所吸引,一直抽不开身.群里面有朋友问博主是否改行做前端了,呵呵,其实博主是想做“全战”, ...
- 优秀API设计的十大原则
优秀API设计的十大原则 2015-09-23 分类:编程开发.设计模式.首页精华暂无人评论 分享到:更多4 二十万年薪PHP工程师培养计划 成为被疯抢的Android牛人 风中叶讲Java重难 ...
- Java 性能测试的四项原则
绝大数的开发人员在日常工作过程中都会或多或少的遇见过性能问题,本文旨在阐述性能测试的理论,从而为性能分析和开发人员做指导.本文对于那些刚刚接触性能调优和正在解决问题的开发人员也能提供一些启发性的思路. ...
- developerWorks 中国 技术主题 Java technology 文档库 Java 性能测试的四项原则
转-https://www.ibm.com/developerworks/cn/java/j-lo-java-performance-testing/?cm_mmc=dwchina-_-homepa ...
- Java设计模式-设计模式的六种原则
所谓无招胜有招,练一门功夫分为内功和外功. 外功好比招式,就是所谓的23种设计模式.而内功呢,就是心法,那就是这6种法则.光会外功那是花拳绣腿,内功修为才是境地. 如此众多的设计模式,学完2遍.3遍可 ...
随机推荐
- 不合法语句 self.contentView.frame.origin.x = x;
下面的写法是错误的: CGFloat x = self.contentView.frame.origin.x; x = _lastDownX + translation.x; self.content ...
- JPA 系列教程14-自定义类型-@Embedded+@Embeddable
自定义类型 在hibernate中实现自定义类型,需要去实现UserType接口即可或者以Component的形式提供. JPA的@Embedded注解有点类似,通过此注解可以在Entity模型中使用 ...
- android代码格式化方法小结
转载:http://blog.csdn.net/androidzhaoxiaogang/article/details/7692526 Download the android-formatting. ...
- HDU 1969 Pie
二分答案+验证(这题精度卡的比较死) #include<stdio.h> #include<math.h> #define eps 1e-7 ; double a[ff]; d ...
- php 项目简单分类
项目分为:客户需求和自行研发. 商城项目:------------------------商城分类:单商家:商家就是网站所有者.如京东.凡客. 多商家:如淘宝 网站所有者不是卖家. ...
- 第十六节,基本数据类型,字典dict
字典 常用操作: 索引 新增 删除 键.值.键值对 循环 长度 字典由键值对组成,由一个键(名称)和 一个值组成,与列表和元组不同的是里面的元素是有键的(名称) 所以当要打印字典时,打印字典变量加[键 ...
- mysql 数据表
CREATE DATABASE IF NOT EXISTS `shop`;USE `shop`; drop table if exists lidepeng; create table lidepe ...
- JSON.stringify 应用
原文:https://technet.microsoft.com/zh-cn/sysinternals/cc836459 url JSON.stringify 函数 将 JavaScript 值转换为 ...
- shell脚本学习(二)
4.cat命令 1) cat -s 摆脱多余的空白行 2) cat -T 将制表符显示为^I 3) cat -n 显示行号 4) cat -b 跳过空白行,然后显示行号 ...
- dns是什么
域名解析服务器,靠它把你要访问的网址找到然后把信息送到你电脑上.DNS 是域名系统 (Domain Name System) 的缩写,它是由解析器和域名服务器组成的.域名服务器是指保存有该网络中所有主 ...