原则_原则中文版pdf下载 - CSDN
精华内容
参与话题
  • 设计模式之七大原则

    热门讨论 2018-12-02 16:21:00
    俗话说:国有国法,家有家规,那在使用设计模式时都需要遵循什么原则呢? 内容  单一职责原则  What   就一个类而言,应该仅有一个引起它变化的原因;  Why   如果一个类承担的职...

    前言

      学习了这么长时间的设计模式,我们知道了设计模式是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。使用设计模式是为了代码可重用性、让代码更容易被他人理解、保证代码可靠性。俗话说:国有国法,家有家规,那在使用设计模式时都需要遵循什么原则呢?

    内容

    这里写图片描述

     单一职责原则

     What
      就一个类而言,应该仅有一个引起它变化的原因;

     Why
      如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏;

     How
      发现职责并把那些职责相互分离。如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个类的职责,就应该考虑类的职责分离;

     开放封闭原则

     What
      软件实体(类、模块、函数等)应该可以扩展,但是不可修改;

     Why
      面对需求的改变可以保持相对稳定,从而使系统可以在第一个版本以后不断推出新的版本;遵循该原则会使程序可维护,可扩展,可复用,灵活性好

     How
      无论模块是多么的“封闭”,都会存在一些无法对之封闭的变化。既然不可能完全封闭,设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类,然后构造抽象来隔离那些变化;当变化发生时,我们就创建抽象来隔离以后发生的同类变化,面对需求时,对程序的改动是通过增加新代码进行的,而不是更改现有的代码;

     依赖倒转原则

     What
      抽象不应该依赖细节,细节应该依赖抽象;针对接口编程,不要对实现编程;高层模块不应该依赖低层模块,两个都依赖抽象;

     Why
       面向对象的编程里强调强内聚,松耦合;CPU独自成为了产品,在千千万万的电脑主板上插上就可以使用,这是由于CPU的对外接口一样,这就是接口的最大好处;

     How
      谁也不要依靠谁,除了约定的接口,大家都可以灵活自如;只要接口是稳定的,那么任何一个更改都不用担心其他受到影响,使得无论高层模块还是低层模块都可以很容易地被复用;

     里氏代换原则

     What
      子类型必须能够替换掉他们的父类型;在软件里面,把父类都替换成他的子类,程序的行为没有变化;

     Why
       子类拥有父类所有非private的行为和属性,所以使继承复用成为了可能;由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展,使得开放-封闭成为了可能;

     How
      只有当子类可以替换掉父类,软件单位的功能不受到影响时,父类才能真正被复用,而子类也能够在父类的基础上增加新的行为;

     迪米特法则(最少知识原则)

     What
      如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用;

     Why
       迪米特法则的根本思想是强调了类之间的松耦合,类之间的耦合越弱,越有利于复用,一个处在弱耦合的类被修改,不会对有关系的类造成波及;

     How
      在类的结构设计上,每一个类都应当尽量降低成员的访问权限,一个类包装好自己的private状态,不需要让别的类知道自己的字段或者行为就不要公开;

     合成/聚合复用原则

     What
      在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分;新的对象通过向这些对象的委派达到复用已有功能的目的;聚合表示一种弱的“拥有”关系,体现的是A对象包含B对象,但B对象不是A对象的一部分;合成则是一种强的“拥有”关系,体现了严格的部分和整体的关系,部分和整体的生命周期是一样的;

     Why
       让各个类尽可能少的跟别人联系,提高其扩展性和维护性;有助于保持每个类被封装,并被集中在单个任务上,保持较小规模;

     How
      尽量使用聚合,尽量不使用继承;

     接口隔离原则

     What
      每一个接口应该是一种角色,不多不少,不干不该干的事,该干的事都要干;一个类对另一个列的依赖应该建立在最小的接口上;

    总结

      学习的过程中不要拘泥于一种形式,一种材料,应该集众家之所长,听取各方意见并进行研究。在使用设计模式的过程中,遵循设计模式的原则。

    展开全文
  • 七大原则

    2016-06-12 18:22:38
    1.开闭原则(Open Close Principle)定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。开放-封闭原则的意思就是说,你设计的时候,时刻要考虑,尽量让这个类是足够好,写好了就不要去修改了,如果新...

    1.开闭原则(Open Close Principle)

    定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。

    开放-封闭原则的意思就是说,你设计的时候,时刻要考虑,尽量让这个类是足够好,写好了就不要去修改了,如果新需求来,我们增加一些类就完事了,原来的代码能不动则不动。这个原则有两个特性,一个是说“对于扩展是开放的”,另一个是说“对于更改是封闭的”。面对需求,对程序的改动是通过增加新代码进行的,而不是更改现有的代码。这就是“开放-封闭原则”的精神所在
    
    比如,刚开始需求只是写加法程序,很快在client类中完成后,此时变化没有发生,需求让再添加一个减法功能,此时会发现增加功能需要修改原来这个类,这就违背了开放-封闭原则,于是你就应该考虑重构程序,增加一个抽象的运算类,通过一些面向对象的手段,如继承、动态等来隔离具体加法、减法与client耦合,需求依然可以满足,还能应对变化。此时需求要添加乘除法功能,就不需要再去更改client及加减法类,而是增加乘法和除法子类即可。
    

    绝对的修改关闭是不可能的,无论模块是多么的‘封闭‘,都会存在一些无法对之封闭的变化,既然不可能完全封闭,设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类,然后构造抽象来隔离那些变化。在我们最初编写代码时,假设变化不会发生,当变化发生时,我们就创建抽象来隔离以后发生同类的变化。

     我们希望的是在开发工作展开不久就知道可能发生的变化,查明可能发生的变化所等待的时候越长,要创建正确的抽象就越困难。开放-封闭原则是面向对象设计的核心所在,遵循这个原则可以带来面向对象技术所声称的巨大好处,也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出现频繁变化的那些部分做出抽象,然而对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意,拒绝不成熟的抽象和抽象本身一样重要。开放-封闭原则,可以保证以前代码的正确性,因为没有修改以前代码,所以可以保证开发人员专注于将设计放在新扩展的代码上。
    

    简单的用一句经典的话来说:过去的事已成历史,是不可修改的,因为时光不可倒流,但现在或明天计划做什么,是可以自己决定(即扩展)的。
    2.里氏代换原则(Liskov Substitution Principle)

    定义1:如果对每一个类型为 T1的对象 o1,都有类型为 T2 的对象o2,使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时,程序 P 的行为没有发生变化,那么类型 T2 是类型 T1 的子类型。

    定义2:子类型必须能够替换掉它们的父类型。
    描述:一个软件实体如果使用的是一个父类的话,那么一定适用于其子类,而且它察觉不出父类对象和子类对象的区别,也就是说,在软件里面,把父类都替换成它的子类,程序的行为没有变化
    例子:在生物学分类上,企鹅是一种鸟,但在编程世界里,企鹅却不能继承鸟。在面向对象设计时,子类拥有父类所有非private的行为和属性,鸟会飞,但企鹅不会飞,所以企鹅不能继承鸟类。

    只有当子类可以替换掉父类,软件单位的功能不受影响时,父类才能真正被复用,而子类也能够在父类的基础上增加新的行为,正是有里氏代换原则,使得继承复用成为了可能。正是由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展,不然还谈什么扩展开放,修改关闭呢
    

    里氏替换原则通俗的来讲就是:子类可以扩展父类的功能,但不能改变父类原有的功能。它包含以下4层含义:

    1.子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法。

    2.子类中可以增加自己特有的方法。

    3.当子类的方法重载父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松。

    4.当子类的方法实现父类的抽象方法时,方法的后置条件(即方法的返回值)要比父类更严格。

    看上去很不可思议,因为我们会发现在自己编程中常常会违反里氏替换原则,程序照样跑的好好的。所以大家都会产生这样的疑问,假如我非要不遵循里氏替换原则会有什么后果?
    

    后果就是:你写的代码出问题的几率将会大大增加。
    3.依赖倒转原则(Dependence Inversion Principle)

    定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。即针对接口编程,不要针对实现编程

    依赖倒转其实就是谁也不要依靠谁,除了约定的接口,大家都可以灵活自如。依赖倒转可以说是面向对象设计的标志,用哪种语言来编写程序不重要,如果编写时考虑的都是如何针对抽象编程而不是针对细节编程,即程序中所有的依赖关系都是终止于抽象类或者接口,那就是面向对象的设计,反之那就是过程化的设计了。如果设计的各个部件或类相互依赖,这样就是耦合度高,难以维护和扩展,这也就体现不出面向对象的好处了。
    
    依赖倒转原则,好比一个团队,有需求组,开发组,测试组,开发组和测试组都是面对同样的需求后,做自己相应的工作,而不应该是测试组按照开发组理解的需求去做测试用例,也就是说开发组和测试组都是直接面向需求组工作,大家的目的是一样的,保证产品按时上线,需求是不依赖于开发和测试的。
    
    依赖倒置原则基于这样一个事实:相对于细节的多变性,抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中,抽象指的是接口或者抽象类,细节就是具体的实现类,使用接口或者抽象类的目的是制定好规范和契约,而不去涉及任何具体的操作,把展现细节的任务交给他们的实现类去完成。
    
    依赖倒置原则的中心思想是面向接口编程,传递依赖关系有三种方式,以上的说的是是接口传递,另外还有两种传递方式:构造方法传递和setter方法传递,相信用过Spring框架的,对依赖的传递方式一定不会陌生。
    

    在实际编程中,我们一般需要做到如下3点:

    低层模块尽量都要有抽象类或接口,或者两者都有。

    变量的声明类型尽量是抽象类或接口。

    使用继承时遵循里氏替换原则。

    总之,依赖倒置原则就是要我们面向接口编程,理解了面向接口编程,也就理解了依赖倒置。
    

    4.接口隔离原则(Interface Segregation Principle)

    接口隔离原则的含义是:建立单一接口,不要建立庞大臃肿的接口,尽量细化接口,接口中的方法尽量少。也就是说,我们要为各个类建立专用的接口,而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。在程序设计中,依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”,通过分散定义多个接口,可以预防外来变更的扩散,提高系统的灵活性和可维护性。

    说到这里,很多人会觉的接口隔离原则跟单一职责原则很相似,其实不然。其一,单一职责原则原注重的是职责;而接口隔离原则注重对接口依赖的隔离。其二,单一职责原则主要是约束类,其次才是接口和方法,它针对的是程序中的实现和细节;而接口隔离原则主要约束接口接口,主要针对抽象,针对程序整体框架的构建。

    采用接口隔离原则对接口进行约束时,要注意以下几点:

    1. 接口尽量小,但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实,但是如果过小,则会造成接口数量过多,使设计复杂化。所以一定要适度。

    2. 为依赖接口的类定制服务,只暴露给调用的类它需要的方法,它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务,才能建立最小的依赖关系。

    3. 提高内聚,减少对外交互。使接口用最少的方法去完成最多的事情。

      运用接口隔离原则,一定要适度,接口设计的过大或过小都不好。设计接口的时候,只有多花些时间去思考和筹划,才能准确地实践这一原则。

    4.组合/聚合复用原则

    就是说要尽量的使用合成和聚合,而不是继承关系达到复用的目的
    该原则就是在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分:新的对象通过向这些对象的委派达到复用已有功能的目的。
    其实这里最终要的地方就是区分“has-a”和“is-a”的区别。相对于合成和聚合,
    继承的缺点在于:父类的方法全部暴露给子类。父类如果发生变化,子类也得发生变化。聚合的复用的时候就对另外的类依赖的比较的少。。
    合成/聚合复用
    ① 优点:
    新对象存取成分对象的唯一方法是通过成分对象的接口;
    这种复用是黑箱复用,因为成分对象的内部细节是新对象所看不见的;

    这种复用支持包装;
    这种复用所需的依赖较少;
    每一个新的类可以将焦点集中在一个任务上;
    这种复用可以在运行时动态进行,新对象可以使用合成/聚合关系将新的责任委派到合适的对象。
    ② 缺点:
    通过这种方式复用建造的系统会有较多的对象需要管理。

    继承复用
    ① 优点:
    新的实现较为容易,因为基类的大部分功能可以通过继承关系自动进入派生类;
    修改或扩展继承而来的实现较为容易。
    ② 缺点:
    继承复用破坏包装,因为继承将基类的实现细节暴露给派生类,这种复用也称为白箱复用;
    如果基类的实现发生改变,那么派生类的实现也不得不发生改变;
    从基类继承而来的实现是静态的,不可能在运行时发生改变,不够灵活。
    6.迪米特法则(Law Of Demeter)

    迪米特法则其根本思想,是强调了类之间的松耦合,类之间的耦合越弱,越有利于复用,一个处在弱耦合的类被修改,不会对有关系的类造成影响,也就是说,信息的隐藏促进了软件的复用。
    
    自从我们接触编程开始,就知道了软件编程的总的原则:低耦合,高内聚。无论是面向过程编程还是面向对象编程,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率。低耦合的优点不言而喻,但是怎么样编程才能做到低耦合呢?那正是迪米特法则要去完成的。
    
    迪米特法则又叫最少知道原则,最早是在1987年由美国Northeastern University的Ian Holland提出。通俗的来讲,就是一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类来说,无论逻辑多么复杂,都尽量地的将逻辑封装在类的内部,对外除了提供的public方法,不对外泄漏任何信息。迪米特法则还有一个更简单的定义:只与直接的朋友通信。首先来解释一下什么是直接的朋友:每个对象都会与其他对象有耦合关系,只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系。耦合的方式很多,依赖、关联、组合、聚合等。其中,我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友,而出现在局部变量中的类则不是直接的朋友。也就是说,陌生的类最好不要作为局部变量的形式出现在类的内部。
    

    一句话总结就是:一个对象应该对其他对象保持最少的了解。
    7.单一职责原则(Single Responsibility Principle)

    定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责,应该仅有一个引起它变化的原因

    说到单一职责原则,很多人都会不屑一顾。因为它太简单了。稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则,在设计软件时也会自觉的遵守这一重要原则,因为这是常识。在软件编程中,谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单,并且被认为是常识,但是即便是经验丰富的程序员写出的程序,也会有违背这一原则的代码存在。为什么会出现这种现象呢?因为有职责扩散。所谓职责扩散,就是因为某种原因,职责P被分化为粒度更细的职责P1和P2。
    

    遵循单一职责原的优点有:

    1.可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多;

    2.提高类的可读性,提高系统的可维护性;

    3.变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。

    需要说明的一点是单一职责原则不只是面向对象编程思想所特有的,只要是模块化的程序设计,都需要遵循这一重要原则。

    展开全文
  • 原则一法则

    2019-06-17 16:23:52
    单一职责原则:一类只做它该做的事。 一个类只做它该做的事情。 单一职责原则想表达的就是"高内聚",写代码最终极的原则只有六个字"高内聚、低耦合",就如同葵花宝典或辟邪剑谱的中心思想就八个字"欲练此功必先...

    单一职责原则:一类只做它该做的事。

    一个类只做它该做的事情。 

    单一职责原则想表达的就是"高内聚",写代码最终极的原则只有六个字"高内聚、低耦合",就如同葵花宝典或辟邪剑谱的中心思想就八个字"欲练此功必先自宫",所谓的高内聚就是一个代码模块只完成一项功能,在面向对象中,如果只让一个类完成它该做的事,而不涉及与它无关的领域就是践行了高内聚的原则,这个类就只有单一职责。我们都知道一句话叫"因为专注,所以专业",一个对象如果承担太多的职责,那么注定它什么都做不好。这个世界上任何好的东西都有两个特征,一个是功能单一,好的相机绝对不是电视购物里面卖的那种一个机器有一百多种功能的,它基本上只能照相;另一个是模块化,好的自行车是组装车,从减震叉、刹车到变速器,所有的部件都是可以拆卸和重新组装的,好的乒乓球拍也不是成品拍,一定是底板和胶皮可以拆分和自行组装的,一个好的软件系统,它里面的每个功能模块也应该是可以轻易的拿到其他系统中使用的,这样才能实现软件复用的目标。

    里氏替换原则:子类必须能够替换基类(父类),否则不应当设计为其子类。

    任何时候都可以用子类型替换掉父类型。

    关于里氏替换原则的描述,Barbara Liskov女士的描述比这个要复杂得多,但简单的说就是能用父类型的地方就一定能使用子类型。里氏替换原则可以检查继承关系是否合理,如果一个继承关系违背了里氏替换原则,那么这个继承关系一定是错误的,需要对代码进行重构。例如让猫继承狗,或者狗继承猫,又或者让正方形继承长方形都是错误的继承关系,因为你很容易找到违反里氏替换原则的场景。需要注意的是:子类一定是增加父类的能力而不是减少父类的能力,因为子类比父类的能力更多,把能力多的对象当成能力少的对象来用当然没有任何问题。

    依赖倒换原则:设计要依赖于抽象而不是具体化。

    面向接口编程。

    该原则说得直白和具体一些就是声明方法的参数类型、方法的返回类型、变量的引用类型时,尽可能使用抽象类型而不用具体类型,因为抽象类型可以被它的任何一个子类型所替代,请参考下面的里氏替换原则

    接口隔离原则:接口要小而专,不能大而全。

    接口要小而专,绝不能大而全。

    臃肿的接口是对接口的污染,既然接口表示能力,那么一个接口只应该描述一种能力,接口也应该是高度内聚的。例如,琴棋书画就应该分别设计为四个接口,而不应设计成一个接口中的四个方法,因为如果设计成一个接口中的四个方法,那么这个接口很难用,毕竟琴棋书画四样都精通的人还是少数,而如果设计成四个接口,会几项就实现几个接口,这样的话每个接口被复用的可能性是很高的。Java中的接口代表能力、代表约定、代表角色,能否正确的使用接口一定是编程水平高低的重要标识。

    开闭原则 :一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。

    软件实体应当对扩展开放,对修改关闭。

    在理想的状态下,当我们需要为一个软件系统增加新功能时,只需要从原来的系统派生出一些新类就可以,不需要修改原来的任何一行代码。

    要做到开闭有两个要点:

    ①抽象是关键,一个系统中如果没有抽象类或接口系统就没有扩展点;

    ②封装可变性,将系统中的各种可变因素封装到一个继承结构中,如果多个可变因素混杂在一起,系统将变得复杂而换乱,如果不清楚如何封装可变性,可以参考《设计模式精解》一书中对桥梁模式的讲解的章节。

    组合/聚合复用原则:尽量使用组合和聚合,少使用继承的关系来达到复用的原则。

    优先使用聚合或合成关系复用代码。

    通过继承来复用代码是面向对象程序设计中被滥用得最多的东西,因为所有的教科书都无一例外的对继承进行了鼓吹从而误导了初学者,类与类之间简单的说有三种关系,Is-A关系、Has-A关系、Use-A关系,分别代表继承、关联和依赖。其中,关联关系根据其关联的强度又可以进一步划分为关联、聚合和合成,但说白了都是Has-A关系,合成聚合复用原则想表达的是优先考虑Has-A关系而不是Is-A关系复用代码,原因嘛可以自己从百度上找到一万个理由,需要说明的是,即使在Java的API中也有不少滥用继承的例子,例如Properties类继承了Hashtable类,Stack类继承了Vector类,这些继承明显就是错误的,更好的做法是在Properties类中放置一个Hashtable类型的成员并且将其键和值都设置为字符串来存储数据,而Stack类的设计也应该是在Stack类中放一个Vector对象来存储数据。记住:任何时候都不要继承工具类,工具是可以拥有并可以使用的,而不是拿来继承的。

    迪米特法则:低耦合,高内聚。

    迪米特法则又叫最少知识原则,一个对象应当对其他对象有尽可能少的了解。

    迪米特法则简单的说就是如何做到"低耦合",门面模式和调停者模式就是对迪米特法则的践行。

    迪米特法则用通俗的话来将就是不要和陌生人打交道,如果真的需要,找一个自己的朋友,让他替你和陌生人打交道。

    展开全文
  • 6大原则

    2018-01-10 15:09:17
    现在编程的主流语言基本上都是面向对象的。如C#,C++,JAVA。我们在使用时,已经构造了一个个...而面向对象的六大原则 主要的目的,就是我们如何设计类,更能很好的利用面向对象的特性  单一职责原则 一个

    现在编程的主流语言基本上都是面向对象的。如C#,C++,JAVA。我们在使用时,已经构造了一个个的类。但是往往由于我们在类内部或外部的设计上存在种 种问题,导致尽管是面向对象的语言,却是面向过程的逻辑,甚至维护起来异常困难。每次增加或修改功能都要改动很多的代码,如履薄冰。而面向对象的六大原则 主要的目的,就是我们如何设计类,更能很好的利用面向对象的特性 
    这里写图片描述


    单一职责原则

    一个类永远只有一个职责

    一套软件就像是一个团队,每个类就是团队中的一个成员。团队如果想稳定的发展。这些类就要各司其职,分工明确。如果类之间的功能出现了混淆,那么软件的 整体结构就会非常的混乱。就像管理学中的一句话,如果一个职责由每个员工负责,那么这个职责就没有员工在负责。 这个原则的概念非常简单,也是非常基础的。很多人尽管没有学习过面向对象的思想,但是经常写代码之后也会不自觉的遵守这个原则。


    Ps: 在遵循单一职责原则的时候,常常会遇到职责扩散的问题。什么是职责扩散呢?这里简单说下,在日志生活中,我们在分类职责时,发现很多平常不受重视的职责, 但是这些职责又不能忽视。于是就依次累加,最后分起类来会无穷无尽(有兴趣的读者可以参考下长尾定理)。为了解决这种问题,我们就需要有一些类,他的职责 比较综合(类似于“其它”)。类似于一个帮助类。但是这个类又不能太复杂了,否则我们就应该考虑怎么把这个类分离开来。究竟这个类的复杂程度到了什么时候 情况下,我们就应该拆分呢?这个需要程序员根据软件自身的复杂情况来判断,没有一个统一的标准。

    ###里氏替换原则

    “Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.” 
    ——“继承必须确保超类所拥有的性质在子类中仍然成立“


    这个原则主要是为了体现面向对象的“继承”特征来提出的。 它的主旨就是,能够使用基类的地方,必然也能够透明的使用其子类,并且保证不会出错。为了保证这种透明的无差别的使用,子类在使用时不应该随意的重写父类 已经定义好的非抽象的方法。因为这些非抽象方法,类似于某种职能或契约,当父类保持这种约定时,子类也应该遵循并保证该特性,而非修改该特性。 我们在写代码的时候,如果一个参数设定的是基类(或接口、抽象类),那么我们传送子类进去,一样可以正常使用。因为基类相对于父类,只是一个更丰富,更具体,更详细的表现形式。而不应该出现,传入父类运行某种方法没有问题,可是传入子类运行时就报错了。这在日常生活中也可以理解,汽车作为父类,他下面有卡车、 轿车。轿车下边又有两厢,三厢等不同的继承。但是无论是哪种汽车(父类)的职能,对于他的子类(卡车或轿车)都应该具有相同的职能,而不是相反的职能。以 至于子类的子类(本例中是两厢轿车)也应该拥有汽车一致的功能。


    我们在写代码中,很容易出现复写了父类的方法后,父类的方法发生了改动,而未考虑到子类的方法也需要作出相应的改动,导致代码出现错误。 通俗一点,可以理解为子类是遗传自父类的。他在各种职能上也应该一脉相承自父类。而不应该随意改变。

    Ps:为什么要叫里氏替换原则呢?这是因为最早提出这个理论的人姓里Liskov。这是计算机中少有的以姓氏命名的东西。

    最少知道原则

    Only talk to your immediate friends。永远只和你的朋友交流。

    我们在学习编程的初期,都会有人告诉我们要遵循“高内聚,低耦合”。而OO中也将“封装”作为对象的基本特征之一。最少知道原则其实体现的就是“高内聚,低耦合”这句话。

    (1)低耦合:一个类对于自己依赖的类,知道的越少越好。不要让一个类依赖过多的类。否则这个类很容受外界的影响,并且因为这种影响要改变自身的代码(自身要适应)。

    (2) 高内聚:将实现逻辑都封装在类的内部,对public方法以外的信 
    息,不轻易暴露给外界。

    这是由于public对外后,相当于是一种契约,一种许诺。你要 再后边的实现中,不断的去兼容这种public,以防止调用它的代码不会报错。 上面这样说,可能有点抽象,这里举个例子。在很多人对另一方的要求,都有一条,社会关系不要复杂。为什么会这样呢?因为一个人如果他和外界的关系越复杂, 他就越不稳定,不怕人找事,就怕事找人。或许他的本性是好的,但是周边的龙鱼混杂,三天两头的总会有事。避免这种问题的最好办法,就是一开始就做一个安静 的美男子。

    接口隔离原则

    一个类对于另外一个类的依赖应该建立在最小的接口上。

    一个接口定义的过于臃肿,则代表他的每一个实现类都要考虑所有的实现逻辑。如果一个类实现了某个接口,也就是说这个类承载了这个接口所有的功能,维护这些功能成为了自己的职责。这就无形中增加了一个类的负担。 
    这里有两点需要说明一下:

    (1)接口定义的小,但是要有限度。对接口细化可以增加灵活性,但是过度细化则会使设计复杂化。同时接口的使用率不高,提高了代码的维护成本。这种极端的体现就是每个接口只含有一个方法,这显然是不合适的。 
    (2)接口隔离原则和单一原则的区别

    共同点:都是尽可能的缩小涉及的范围。 
    不同点:单一原则主要是指封装性。他针对的是一个类、一个方法,是从对象的角度考虑的。而接口隔离原则是指类之间的耦合应该保持的一个度。他针对的是类(对象)和类(对象)之间的关系。如果说单一原则指的是思想单纯,那么接 口隔离指的就是社会关系简单啦。

    依赖置换原则

    这个原则的名字比较唬人,我们先看看他的内容究竟是什么。在设计模式中对该原则有两句经典的描述:

    (1)高层模块不应该依赖底层模块。两者都应该依赖抽象。 
    (2)抽象不应该依赖细节,细节应该依赖抽象。


    这两句话的含义是:高层模块不应该依赖底层模块。两者应该通过抽象的东西进行关系链接(抽象的东西是指接口或者抽象类)。其次抽象类或者一个接口不应该依赖某个实现类。而这些实现类反而应该依赖于这个抽象类的设定。


    通俗一点的说法就是,模块之间不应该直接产生调用关系(这是旧有的调用关系),两者应该通过面向接口(或者理解为面向设定的契约)进行编程。而这些契约和接 口更不应该以来自底层模块而设定。这些底层模块反而应该遵守这些契约。因为契约(抽象类、接口)相对于哪些实现代码,更不会改变,也就是更稳定。所以依赖 置换原则又叫作面向接口编程或面向契约编程。本意就是调整原来的依赖关系,重行进行了设定。

    开闭原则

    开闭原则是指:一个软件、一套系统在开发完成后,当有增加或修改需求时,应该对拓展代码打开,对修改原有代码关闭。

    类一旦确定,就不应该再对其功能发生修改。这 是面向对象设计中,最重要最核心的原则。方案发布后,我们最担心的是什么?就是需求的变化,而需求一旦有变化,就要修改代码。大部分的bug往往就是这时 候引入的。因为修改代码时,我们往往将重点放在,如何解决当前bug上,反而没有注意因为这个修改,对原有设计的影响。

    这条原则没有具体的指导要求,是前边五条原则的根本。

    ps: 这六个面向对象的原则,并不是是和否的问题,也不是遵守和不遵守的问题。而是遵守的多和遵守的少的问题。我在文中也多次强调,我们在设计时,应该注意把握 一个度。诚然尽可能的遵守这些原则,会使代码维护起来更容易。但是维护粒度过细,所需要的设计和开发成本成倍增加,这显然是舍本逐末的。如图,面向对象开 发原则可以从以下这个坐标图展示,不论是哪个维度,他的值都不应该过满,甚至溢出,当然也不能很低,保持一个适当的度即可

    展开全文
  • 设计模式六大原则

    千次阅读 2018-09-06 14:38:04
    关于设计模式的六大设计原则的资料网上很多,但是很多地方解释地都太过于笼统化,我也找了很多资料来看,发现CSDN上有几篇关于设计模式的六大原则讲述的比较通俗易懂,因此转载过来。  原作者博客链接:...
  • A 生活原则   A1 生活原则概要与列表   独立思考并决定:(1)你想要什么;(2)事实是什么;(3)面对事实,你如何实现自己的愿望,而且要保持谦逊和心胸开阔,以便你能动用自己的最佳思维。   A2 生活...
  • 原则

    2018-09-10 00:06:47
    1.我这一生犯了很多错误,花了很多时间反省这些错误,在这个过程中,我总结出自己的原则。从很小的时候起,我就是一个充满好奇心的、独立的思考者,追求大胆的目标。我激动地在头脑中设想要追求的东西,在追求的过程...
  • 设计模式六大原则(6):开闭原则

    万次阅读 多人点赞 2012-03-27 15:13:09
    定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。 问题由来:在软件的生命周期内,因为变化、升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误... 开闭原则是面向对象设计中
  • 性能测试理论之二八原则

    万次阅读 2016-01-04 17:34:55
    在性能测试方法论中,很典型的方法就是二八原则,量化业务需求。 二八原则:指80%的业务量在20%的时间里完成。 如何理解,下面我们来个例子吧 用户登录场景:早高峰时段,8:50---9:10,5000坐席上线登陆。  ...
  • 信息专家原则(Information Expert Principle) (1)问题 给对象分配职责的通用原则是什么? (2)方案 将职责分配给拥有履行一个职责所必需信息的类,即信息专家。 (3)分析 信息专家原则是面向对象设计的最基本...
  • 数据库设计的基本原则和主要步骤

    万次阅读 2018-11-20 14:16:32
    数据库设计的基本原则: (1)把具有同一个主题的数据存储在一个数据表中,“一表一用”。 (2)尽量消除冗余,提高访问数据库的速度。 (3)一般要求数据库设计达到第三范式,多对多,最大限度消除了数据冗余、...
  • java设计模式系列的7大设计模式

    万次阅读 2019-11-08 15:18:05
    一、单一职责模式 二、接口隔离模式 三、依赖倒转原则 四、里氏替换原则 五、开闭原则 (英文OCP) 六、迪米特法则 七、合成复用原则
  • 面向对象设计原则概述

    万次阅读 多人点赞 2013-12-22 22:15:12
    在面向对象设计中,可维护性的复用是以设计原则为基础的。每一个原则都蕴含一些面向对象设计的思想,可以从不同的角度提升一个软件结构的设计水平。  面向对象设计原则为支持可维护性复用而诞生,这些原则蕴含在很...
  • 代码设计的六大原则

    万次阅读 2018-07-03 15:17:27
    现在主要针对的是代码设计的原则,在设计代码的时候,不能总是想到哪就打到哪,还需要有个大致的流程,否则写出来的代码也是很繁冗,不够简洁。对于自己的代码编程还没达到一个期望的程度,对于代码的设计。主要注意...
  • 设计模式(一)--六大原则

    万次阅读 2015-02-28 15:02:10
    1、开闭原则 对扩展开放,对修改关闭,最核心的原则使用java的访问权限控制 2、单一职责原则 按照业务逻辑划分,每个类或者接口只有一种职责,也就是只有一种情况会引起类或者接口的变化 3、里氏替换原则 ...
  • 设计排版四大原则,我重复N次了!

    万次阅读 2017-03-21 15:36:44
    设计排版四大原则,真的很受用。在移动端设计时,自我认为最重要的就是版式。就算你图形文字设计的在美妙,如果排版不整洁,看上去也是一团糟。
  • 微服务拆分原则和方法

    千次阅读 2018-05-30 10:11:47
    1. 单一职责、高内聚低耦合2. 服务粒度适中3. 考虑团队结构4. 以业务模型切入5. 演进式拆分6. 避免环形依赖与双向依赖
  • 面向对象设计原则之开闭原则

    万次阅读 多人点赞 2012-05-06 21:39:33
    开闭原则是面向对象的可复用设计的第一块基石,它是最重要的面向对象设计原则。开闭原则由Bertrand Meyer于1988年提出,其定义如下: 开闭原则(Open-Closed Principle, OCP):一个软件实体应当对扩展开放...
  • 交易响应时间258原则

    万次阅读 2012-04-18 16:37:31
    所谓的“2-5-8原则”,简单说,就是当用户能够在2秒以内得到响应时,会感觉系统的响应很快;当用户在2-5秒之间得到响应时,会感觉系统的响应速度还可以;当用户在5-8秒以内得到响应时,会感觉系统的响应速度很慢,...
  • 响应时间2/5/10原则 软件测试2-8原则(2/8原则,二八原则)  2009-07-14 10:21:32| 分类: 默认分类 |字号 订阅 在学习Loadrunner中,接触到2/5/10原则。所谓的“2-5-10原则”,简单...
1 2 3 4 5 ... 20
收藏数 1,073,620
精华内容 429,448
关键字:

原则