精华内容
下载资源
问答
  • 设计模式六大原则
  • 分别就是Java设计模式六大原则和常用的23种设计模式了。本篇是对六大原则的整理。(最后一种是哈姆雷特)1.开闭原则(Open Close Principle)定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。 开放-...

    对于Java看到过一个很有意思的说法:Java有六大心法,23种武功招式。

    分别就是Java设计模式六大原则和常用的23种设计模式了。

    本篇是对六大原则的整理。(最后一种是哈姆雷特)

    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. 提高内聚,减少对外交互。使接口用最少的方法去完成最多的事情。
       运用接口隔离原则,一定要适度,接口设计的过大或过小都不好。设计接口的时候,只有多花些时间去思考和筹划,才能准确地实践这一原则。

     

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

     

    6.单一职责原则(Single Responsibility Principle)
    定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责,应该仅有一个引起它变化的原因
        说到单一职责原则,很多人都会不屑一顾。因为它太简单了。稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则,在设计软件时也会自觉的遵守这一重要原则,因为这是常识。在软件编程中,谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单,并且被认为是常识,但是即便是经验丰富的程序员写出的程序,也会有违背这一原则的代码存在。为什么会出现这种现象呢?因为有职责扩散。所谓职责扩散,就是因为某种原因,职责P被分化为粒度更细的职责P1和P2。
    遵循单一职责原的优点有:
    1.可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多;
    2.提高类的可读性,提高系统的可维护性;
    3.变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。
    需要说明的一点是单一职责原则不只是面向对象编程思想所特有的,只要是模块化的程序设计,都需要遵循这一重要原则。

     

    7.组合/聚合复用原则
    就是说要尽量的使用合成和聚合,而不是继承关系达到复用的目的
    该原则就是在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分:新的对象通过向这些对象的委派达到复用已有功能的目的。
          其实这里最终要的地方就是区分“has-a”和“is-a”的区别。相对于合成和聚合,
    继承的缺点在于:父类的方法全部暴露给子类。父类如果发生变化,子类也得发生变化。聚合的复用的时候就对另外的类依赖的比较的少。。
    合成/聚合复用
    ① 优点:
    新对象存取成分对象的唯一方法是通过成分对象的接口;
     这种复用是黑箱复用,因为成分对象的内部细节是新对象所看不见的;
     这种复用支持包装;
    这种复用所需的依赖较少;
    每一个新的类可以将焦点集中在一个任务上;
     这种复用可以在运行时动态进行,新对象可以使用合成/聚合关系将新的责任委派到合适的对象。
    ② 缺点:
    通过这种方式复用建造的系统会有较多的对象需要管理。
    继承复用
    ① 优点:
      新的实现较为容易,因为基类的大部分功能可以通过继承关系自动进入派生类;
      修改或扩展继承而来的实现较为容易。
    ② 缺点:
      继承复用破坏包装,因为继承将基类的实现细节暴露给派生类,这种复用也称为白箱复用;如果基类的实现发生改变,那么派生类的实现也不得不发生改变;从基类继承而来的实现是静态的,不可能在运行时发生改变,不够灵活。

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

    2019-04-23 21:40:42
    孙玉山主编的设计模式所有设计模式+体系结构题目案例源码
  • 1.单一职责原则: 不要存在多于一个导致类变更的原因 ...接口隔离原则告诉我们在设计接口的时候要精简单一;迪米特法则告诉我们要降低耦合。而开闭原则是总纲,他告诉我们要对扩展开放,对修改关闭。
  • Java设计模式六大原则

    千次阅读 2018-03-20 13:59:09
    单一职责原则 单一职责原则是最简单的面向对象设计原则,它用于控制类的粒度大小。单一职责原则定义如下:单一职责原则(Single Responsibility Principle, SRP):一个类只负责一个功能领域中的相应职责,或者可以...
    一.单一职责原则
    

      单一职责原则是最简单的面向对象设计原则,它用于控制类的粒度大小。单一职责原则定义如下:

    单一职责原则(Single Responsibility Principle, SRP):一个类只负责一个功能领域中的相应职责,或者可以定义为:就一个类而言,应该只有一个引起它变化的原因。

          单一职责原则告诉我们:一个类不能太“累”!在软件系统中,一个类(大到模块,小到方法)承担的职责越多,它被复用的可能性就越小,而且一个类承担的职责过多,就相当于将这些职责耦合在一起,当其中一个职责变化时,可能会影响其他职责的运作,因此要将这些职责进行分离,将不同的职责封装在不同的类中,即将不同的变化原因封装在不同的类中,如果多个职责总是同时发生改变则可将它们封装在同一类中。

          单一职责原则是实现高内聚、低耦合的指导方针,它是最简单但又最难运用的原则,需要设计人员发现类的不同职责并将其分离,而发现类的多重职责需要设计人员具有较强的分析设计能力和相关实践经验。

          下面通过一个简单实例来进一步分析单一职责原则:

    Sunny软件公司开发人员针对某CRM(Customer Relationship  Management,客户关系管理)系统中客户信息图形统计模块提出了如图1所示初始设计方案:


    图1  初始设计方案结构图


    在图1中,CustomerDataChart类中的方法说明如下:getConnection()方法用于连接数据库,findCustomers()用于查询所有的客户信息,createChart()用于创建图表,displayChart()用于显示图表。

    现使用单一职责原则对其进行重构。

          在图1中,CustomerDataChart类承担了太多的职责,既包含与数据库相关的方法,又包含与图表生成和显示相关的方法。如果在其他类中也需要连接数据库或者使用findCustomers()方法查询客户信息,则难以实现代码的重用。无论是修改数据库连接方式还是修改图表显示方式都需要修改该类,它不止一个引起它变化的原因,违背了单一职责原则。因此需要对该类进行拆分,使其满足单一职责原则,类CustomerDataChart可拆分为如下三个类:

          (1) DBUtil:负责连接数据库,包含数据库连接方法getConnection();

          (2) CustomerDAO:负责操作数据库中的Customer表,包含对Customer表的增删改查等方法,如findCustomers();

          (3) CustomerDataChart:负责图表的生成和显示,包含方法createChart()和displayChart()。

          使用单一职责原则重构后的结构如图2所示:




                                              图2  重构后的结构图

    二.开闭原则

          例子地址:http://mp.csdn.net/postedit/79622068

      开闭原则是面向对象的可复用设计的第一块基石,它是最重要的面向对象设计原则。开闭原则由Bertrand  Meyer于1988年提出,其定义如下:

    开闭原则(Open-Closed Principle, OCP):一个软件实体应当对扩展开放,对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。

          在开闭原则的定义中,软件实体可以指一个软件模块、一个由多个类组成的局部结构或一个独立的类。

          任何软件都需要面临一个很重要的问题,即它们的需求会随时间的推移而发生变化。当软件系统需要面对新的需求时,我们应该尽量保证系统的设计框架是稳定的。如果一个软件设计符合开闭原则,那么可以非常方便地对系统进行扩展,而且在扩展时无须修改现有代码,使得软件系统在拥有适应性和灵活性的同时具备较好的稳定性和延续性。随着软件规模越来越大,软件寿命越来越长,软件维护成本越来越高,设计满足开闭原则的软件系统也变得越来越重要。

          为了满足开闭原则,需要对系统进行抽象化设计,抽象化是开闭原则的关键。在Java、C#等编程语言中,可以为系统定义一个相对稳定的抽象层,而将不同的实现行为移至具体的实现层中完成。在很多面向对象编程语言中都提供了接口、抽象类等机制,可以通过它们定义系统的抽象层,再通过具体类来进行扩展。如果需要修改系统的行为,无须对抽象层进行任何改动,只需要增加新的具体类来实现新的业务功能即可,实现在不修改已有代码的基础上扩展系统的功能,达到开闭原则的要求。

    三、里氏替换原则

    里氏代换原则告诉我们,在软件中将一个基类对象替换成它的子类对象,程序将不会产生任何错误和异常,反过来则不成立,如果一个软件实体使用的是一个子类对象的话,那么它不一定能够使用基类对象。例如:我喜欢动物,那我一定喜欢狗,因为狗是动物的子类;但是我喜欢狗,不能据此断定我喜欢动物,因为我并不喜欢老鼠,虽然它也是动物。

          例如有两个类,一个类为BaseClass,另一个是SubClass类,并且SubClass类是BaseClass类的子类,那么一个方法如果可以接受一个BaseClass类型的基类对象base的话,如:method1(base),那么它必然可以接受一个BaseClass类型的子类对象sub,method1(sub)能够正常运行。反过来的代换不成立,如一个方法method2接受BaseClass类型的子类对象sub为参数:method2(sub),那么一般而言不可以有method2(base),除非是重载方法。

          里氏代换原则是实现开闭原则的重要方式之一,由于使用基类对象的地方都可以使用子类对象,因此在程序中尽量使用基类类型来对对象进行定义,而在运行时再确定其子类类型,用子类对象来替换父类对象

          在使用里氏代换原则时需要注意如下几个问题:

          (1)子类的所有方法必须在父类中声明,或子类必须实现父类中声明的所有方法。根据里氏代换原则,为了保证系统的扩展性,在程序中通常使用父类来进行定义,如果一个方法只存在子类中,在父类中不提供相应的声明,则无法在以父类定义的对象中使用该方法。

          (2) 我们在运用里氏代换原则时,尽量把父类设计为抽象类或者接口,让子类继承父类或实现父接口,并实现在父类中声明的方法,运行时,子类实例替换父类实例,我们可以很方便地扩展系统的功能,同时无须修改原有子类的代码,增加新的功能可以通过增加一个新的子类来实现。里氏代换原则是开闭原则的具体实现手段之一。

          (3) Java语言中,在编译阶段,Java编译器会检查一个程序是否符合里氏代换原则,这是一个与实现无关的、纯语法意义上的检查,但Java编译器的检查是有局限的。

          在Sunny软件公司开发的CRM系统中,客户(Customer)可以分为VIP客户(VIPCustomer)和普通客户(CommonCustomer)两类,系统需要提供一个发送Email的功能,原始设计方案如图1所示:

    1原始结构图

          在对系统进行进一步分析后发现,无论是普通客户还是VIP客户,发送邮件的过程都是相同的,也就是说两个send()方法中的代码重复,而且在本系统中还将增加新类型的客户。为了让系统具有更好的扩展性,同时减少代码重复,使用里氏代换原则对其进行重构。

          在本实例中,可以考虑增加一个新的抽象客户类Customer,而将CommonCustomer和VIPCustomer类作为其子类,邮件发送类EmailSender类针对抽象客户类Customer编程,根据里氏代换原则,能够接受基类对象的地方必然能够接受子类对象,因此将EmailSender中的send()方法的参数类型改为Customer,如果需要增加新类型的客户,只需将其作为Customer类的子类即可。重构后的结构如图2所示:

    图2  重构后的结构图

    四、依赖倒置原则

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

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

    五、接口隔离原则(Interface Segregation Principle)
       接口隔离原则的含义是:建立单一接口,不要建立庞大臃肿的接口,尽量细化接口,接口中的方法尽量少。也就是说,我们要为各个类建立专用的接口,而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。在程序设计中,依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”,通过分散定义多个接口,可以预防外来变更的扩散,提高系统的灵活性和可维护性。
       说到这里,很多人会觉的接口隔离原则跟单一职责原则很相似,其实不然。其一,单一职责原则原注重的是职责;而接口隔离原则注重对接口依赖的隔离。其二,单一职责原则主要是约束类,其次才是接口和方法,它针对的是程序中的实现和细节;而接口隔离原则主要约束接口接口,主要针对抽象,针对程序整体框架的构建。
    采用接口隔离原则对接口进行约束时,要注意以下几点:
    1. 接口尽量小,但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实,但是如果过小,则会造成接口数量过多,使设计复杂化。所以一定要适度。
    2. 为依赖接口的类定制服务,只暴露给调用的类它需要的方法,它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务,才能建立最小的依赖关系。
    3. 提高内聚,减少对外交互。使接口用最少的方法去完成最多的事情。

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

      

      Sunny软件公司开发人员针对某CRM系统的客户数据显示模块设计了如图1所示接口,其中方法dataRead()用于从文件中读取数据,方法transformToXML()用于将数据转换成XML格式,方法createChart()用于创建图表,方法displayChart()用于显示图表,方法createReport()用于创建文字报表,方法displayReport()用于显示文字报表。

    1 初始设计方案结构图

          在实际使用过程中发现该接口很不灵活,例如如果一个具体的数据显示类无须进行数据转换(源文件本身就是XML格式),但由于实现了该接口,将不得不实现其中声明的transformToXML()方法(至少需要提供一个空实现);如果需要创建和显示图表,除了需实现与图表相关的方法外,还需要实现创建和显示文字报表的方法,否则程序编译时将报错。

          现使用接口隔离原则对其进行重构。

          在图1中,由于在接口CustomerDataDisplay中定义了太多方法,即该接口承担了太多职责,一方面导致该接口的实现类很庞大,在不同的实现类中都不得不实现接口中定义的所有方法,灵活性较差,如果出现大量的空方法,将导致系统中产生大量的无用代码,影响代码质量;另一方面由于客户端针对大接口编程,将在一定程序上破坏程序的封装性,客户端看到了不应该看到的方法,没有为客户端定制接口。因此需要将该接口按照接口隔离原则和单一职责原则进行重构,将其中的一些方法封装在不同的小接口中,确保每一个接口使用起来都较为方便,并都承担某一单一角色,每个接口中只包含一个客户端(如模块或类)所需的方法即可。

          通过使用接口隔离原则,本实例重构后的结构如图2所示:

    2 重构后的结构图

    六、迪米特法则(Law Of Demeter)

      迪米特法则其根本思想,是强调了类之间的松耦合,类之间的耦合越弱,越有利于复用,一个处在弱耦合的类被修改,不会对有关系的类造成影响,也就是说,信息的隐藏促进了软件的复用。
      迪米特法则要求我们在设计系统时,应该尽量减少对象之间的交互,如果两个对象之间不必彼此直接通信,那么这两个对象就不应当发生任何直接的相互作用,如果其中的一个对象需要调用另一个对象的某一个方法的话,可以通过第三者转发这个调用。简言之,就是通过引入一个合理的第三者来降低现有对象之间的耦合度。
       在将迪米特法则运用到系统设计中时,要注意下面的几点:在类的划分上,应当尽量创建松耦合的类,类之间的耦合度越低,就越有利于复用,一个处在松耦合中的类一旦被修改,不会对关联的类造成太大波及;在类的结构设计上,每一个类都应当尽量降低其成员变量和成员函数的访问权限;在类的设计上,只要有可能,一个类型应当设计成不变类;在对其他类的引用上,一个对象对其他对象的引用应当降到最低。
       下面通过一个简单实例来加深对迪米特法则的理解:

     Sunny软件公司所开发CRM系统包含很多业务操作窗口,在这些窗口中,某些界面控件之间存在复杂的交互关系,一个控件事件的触发将导致多个其他界面控件产生响应,例如,当一个按钮(Button)被单击时,对应的列表框(List)、组合框(ComboBox)、文本框(TextBox)、文本标签(Label)等都将发生改变,在初始设计方案中,界面控件之间的交互关系可简化为如图1所示结构:

    1 初始设计方案结构图

          在图1中,由于界面控件之间的交互关系复杂,导致在该窗口中增加新的界面控件时需要修改与之交互的其他控件的源代码,系统扩展性较差,也不便于增加和删除新控件。

          现使用迪米特对其进行重构。

          在本实例中,可以通过引入一个专门用于控制界面控件交互的中间类(Mediator)来降低界面控件之间的耦合度。引入中间类之后,界面控件之间不再发生直接引用,而是将请求先转发给中间类,再由中间类来完成对其他控件的调用。当需要增加或删除新的控件时,只需修改中间类即可,无须修改新增控件或已有控件的源代码,重构后结构如图2所示:

    2  重构后的结构图


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

    千次阅读 2017-04-09 08:46:56
    六大原则 1. 单一职责原则 Single Responsibility Principle SRP原则 分清职责,接口一定要做到单一职责,方法也要做到,类尽量做到 定义:单一职责原则指的是应该有且仅有一个原因引起类的变更。 2. 里氏...


    面向对象的设计,我们通常会涉及到两个元素:接口,类,及他们之间的协作关系。
    对于接口的设计:需要考虑接口隔离原则
    对于类的设计:需要考虑类本身的设计,需要考虑类的职责是否单一;对于有继承关系的类设计,要注意子类是否改变父类的方法,目标是不要改变,子类应该只扩展父类的行为(里氏替换原则开闭原则),这样才能把将来子类变化时产生的影响缩小到最小的范围。
    对于协作关系的设计:做顶层的框架设计时,协作应该是接口之间发生关系,接口之间的调用(依赖倒置原则),当1个类需要和 其他类发生调用关系时,可以考虑增加1个中间者来转发调用关系(迪米特法则,不常用),缩小类更变影响的范围。

    笔记来源---设计模式之禅(秦小波著)

    六大原则


    1. 单一职责原则

    Single Responsibility Principle SRP原则

    分清职责,接口一定要做到单一职责,方法也要做到,类尽量做到

    定义单一职责原则指的是应该有且仅有一个原因引起类的变更

    2. 里氏替换原则

    Liskov Substitution Principle LSP原则

    定义:所有引用基类的地方必须能透明地使用其子类的对象,通俗的来讲就是父类能出现的地方子类就可以出现,但是反过来就不行了。子类可以扩展父类的功能,但不能改变父类原有的功能。

    里氏替换原则为良好的继承定义了一个规范;

    在类中调用其他类时务必要使用父类或者接口,如果不能使用父类或者接口,则说明类的设计已经违背了LSP原则;

    我们在做系统设计时,经常会定义一个接口或者抽象类,然后编码实现,调用类则直接传入接口或者抽象类,不关心具体实现;

    如果子类不能完整地实现父类的方法,或者父类的某些方法在子类中已经发生“畸变”,则建议断开父子继承关系,采用依赖、聚集、组合等关系代替继承;

    在项目中采用里氏替换原则时,尽量避免子类的个性,一旦子类有个性这个子类和父类的关系就很难调和了。

    定义包含四层意思:

    1) 子类可以实现父的抽象方法,但不能覆写父类的非抽象方法。 父类中凡是已经实现好的方法(相对于抽象方法而言),实际上是在设定一系列的规范和契约,虽然它不强制要求所有的子类必须遵从这些契约,但是如果子类对这些非抽象方法任意修改,就会对整个继承体系造成破坏。

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

    3) 覆写 或实现父类的方法时,输入参数可以被放大。(覆写指的覆写一个正常方法并重写,是实现指的是实现接口或者抽象方法)

    4) 覆写或实现父类的方法时输出结果可以被缩小(若放大,还能用子类替换父类吗?)

    3. 依赖倒置原则

    Dependence Inversion Principle DIP原则

    定义:

    1)高层模块不应该依赖低层模块

    2)抽象不应该依赖细节

    3)细节依赖抽象

    在Java中的表现为:面向接口编程 OOP

    1)模块间的依赖通过抽象发生,实现类间不发生直接的依赖关系,其依赖关系通过接口或者抽象类产生;

    2)接口或抽象类不依赖于实现类

    3)实现类依赖于接口或者抽象类

    依赖倒置原则可以减少类之间的耦合性,提高系统的稳定性;降低并行开发引起的风险。

    要并行开发就要解决模块间的依赖关系,依赖倒置原则正好解决这个问题。

    在Java中,只要定义变量就必然要有类型,一个变量可以有两种类型,表面类型和实际类型,UserDao是表面类型,UserDaoImpl是实际类型。

    依赖的三种写法:依赖是可以传递的,只要做到抽象依赖,即使是多层的依赖也没关系。

    1)构造函数传递依赖对象

    2)Setter方法传递依赖对象

    3)接口方法中传入依赖对象

    最佳实践:

    1)每个类尽量都有接口或者抽象类

    2)变量的表面类型尽量是接口或者抽象类

    3)不从具体类派生类

    4)尽量不覆写基类的方法,只实现;

    倒置的概念就是所谓的抽象依赖。

    4. 接口隔离原则

    Interface Segregation Principle ISP原则

    把一个臃肿的接口变更为两个独立的接口所依赖的原则就是接口隔离原则;

    定义

    客户端不应该依赖它不需要的接口

    类间的依赖关系应该建立在最小的接口上;

    根据接口隔离原则拆分接口时,首先必须满足单一职责原则;

    接口要高内聚,高内聚就是提高接口、类、模块的处理能力,减少对外交互。

    定制服务,为不同的用户定制不同的服务

    接口设计要适度,各方都要照顾。

    接口和类尽量使用院子接口或原子类来组装,但是这个原子接口或原子类该怎么组装,是一个难题。在实践中可根据以下标准来衡量:

    1)一个接口只服务于一个字模块或业务逻辑

    2)通过业务逻辑压缩接口中的public方法

    3)已被污染的接口尽量去修改,若变更风险大,可用适配器模式进行转化处理

    4)了解业务背景,避免生搬硬套模式。

    开发中只能根据,经验和常识来判断接口粒度的大小。

    5. 迪米特法则

    Law of Demter LoD

    也称为最少知识原则:Least Knowledge Principle LKP

    描述的是,一个对象应该对其他对象有最少的了解,一个类只需要知道自己需要耦合或者调用类的public方法即可。

    尽量保证风险的不扩散,修改的地方越少,代码就越好。

    一个类公开的public方法越多,修改时涉及的面也越大,变更的风险也越大。

    只和朋友交流:

    朋友类的定义:出现在成员变量、方法的输入输出参数中的类称为成员朋友类,而出现在方法体内部的类不属于朋友类,迪米特法则告诉我们,一个类 只和他的朋友类做交流,老师和体育委员交流、体育委员和学生交流。

    在实际中如果遇到,一个方法放在本类中也可以,放在其他类中也合适,那么你可以坚持这样一个原则:如果一个方法放在本类中,既不增加类间关系,也 对本类不产生负面影响,那就放置在本类中。

    迪米特法则的核心观念就是类间的解耦,弱耦合。但是也要衡量,既要让结构清晰,又要高内聚低耦合。

    我们在使用原则时,要反复衡量。

    6. 开闭原则

    Java世界里最基础的设计原则

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

    根据3W原则介绍

    什么是开闭原则?

    软件实体包括:项目或者软件产品中按照一定的逻辑规则划分的模块。

    抽象和类

    方法

    一个软件产品在开发周期内,肯定会有变化,我们的设计应该尽量适应这些变化,开闭原则则告诉我们尽量通过扩展软件实体的行为来实现变化,而不是修改已有的代码来完成变化。

    为什么使用开闭原则? -- 重要性

    前五章介绍的原则都是开闭原则的具体形态,开闭原则是精神领袖。

    对测试的影响

    可提高复用性

    可提高可维护性

    面向对象开发的要求

    如何使用开闭原则?

    开闭原则是非常虚的一个原则;

    抽象约束、元数据控制模块行为、制定项目章程、封装变化;

    封装变化有两层含义,第一将相同的变化封装到一个接口或抽象类中;第二,将不同的变化封装到不同的接口或抽象类中。23种设计模式都是从各个不同的角度对变化进行封装的;

    总结:

    Single Responsibility Principle

    Open Closed Principle

    Liskov Substitution Principle

    Law of Demeter

    Interface Segregation Principle

    Dependence Inversion Principle

    这六个字母联合起来 Solid 稳定的;

    展开全文
  • java程序设计六大原则

    千次阅读 2019-04-01 16:10:13
    六大设计原则 一、单一职责原则(single responsibility principle)简称SRP原则: 一个接口或者类只有一个原因引起变化,即一个接口或者类只有一个职责,负责一件事情。(此原则同样适用于方法) 好处: 1、复杂性...

    (2019年04月阅读《设计模式之禅》-秦小波,阅读后自己总结如下)

    六大设计原则
    一、单一职责原则(single responsibility principle)简称SRP原则:
    一个接口或者类只有一个原因引起变化,即一个接口或者类只有一个职责,负责一件事情。(此原则同样适用于方法)
    好处:
    1、复杂性降低;2、可读性提高;3、可维护性提高;4、变更风险降低

    二、里氏替换原则:父类能出现的地方子类就可以出现。
    定义解释:
    1、子类必须完全实现父类的方法;
    2、子类可以有自己的个性;
    3、覆盖或者实现父类的方法时,输入参数可以被放大;
    public class Father {
        public Collection doSomething(HashMap map) {
            System.out.println("父类被执行了");
            return map.values();
        }
    }

    public class Son extends Father {
        public Collection  doSomething(Map  map) {
            System.out.println("子类被执行了");
            return map.values();
        }    
    }
    public static void main(String[] args) {
        Father father = new Father();
        Son son = new Son();
        HashMap<Object,Object> map = new HashMap<>();
        
        father.doSomething(map);
        son.doSomething(map);
    }
    以上代码执行时,子类重载了父类的doSomething方法,并且放大输入参数Hashmap→Map,执行以后,出现相同的结果,
    均输出"父类被执行了",并没有歪曲父类的意图,不会引起业务逻辑混乱,符合里氏替换原则。
    4、覆写或者实现父类的方法时,输出结果可以被缩小;

    三、依赖倒置原则:
    1、高层不应该依赖底层,两者都应该依赖其抽象;
    2、抽象不应该依赖细节,细节应该依赖抽象;
    即模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或者抽象类产生的。
    更加简单的定义就是"面向接口编程(OOD:Object-Oriented Design)"

    四、接口隔离原则
    定义解释:
    1、接口要尽量小
    2、接口要高内聚,高内聚就是尽量减少公布public方法
    3、接口要为个体提供定制服务,即只提供访问者需要的方法
    4、接口设计是有限度的
    通俗的讲,接口尽量细化,同时接口中的方法尽量少。
    说明:单一职责原则侧重于业务逻辑,即职责尽量少;而接口隔离原则侧重于接口中的方法尽量少。

    五、迪米特法则
    也称为最少知识原则:一个对象应该对其他对象有最少的了解。通俗的讲:一个类应该对自己需要耦合或者调用的类知道的越少越好

    六、开闭原则
    软件实体应该对扩展开放,对修改关闭。就是说应该通过扩展来实现变化,而不是通过修改已有的代码来实现变化。

    展开全文
  • 定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。 问题由来:在软件的生命周期内,因为变化、升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误,也可能会... 开闭原则是面
  • 定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。 问题由来:类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改...解决方案:遵循单一职责原则。分别建立两
  • Java设计模式6大原则

    千次阅读 2019-03-01 18:50:45
    设计模式的6大原则,单一职责原则,开放封闭原则,里式替换原则,依赖导致原则,迪米特原则和接口隔离原则。
  • 详细介绍了设计模式六大原则,配有示例代码和图片,有开闭原则,单一职责原则,里氏替换原则,依赖倒置原则,接口隔离原则,迪米特法则等等。
  • 个人结合实例对java设计模式六大原则的理解:单一职责原则;里氏替换原则;依赖倒置原则。
  • JAVA设计模式】设计六大原则

    千次阅读 多人点赞 2018-12-28 09:02:18
    - 单一职责原则(SRP) 定义:就一个类而言,应该仅有一个引起它变化的原因。 从这句定义我们很难理解它的含义,通俗讲就是我们不要让一个类承担过多的职责。如果一个类承担的职责过多,就等于把这些职责耦合在一起...
  • JAVA六大设计原则 和 23种设计模式

    千次阅读 2019-04-02 21:22:17
    相关书籍:《大话设计模式》、《Java设计...JAVA设计模式提供个基本原则,分别是: 开闭原则(OCP) - The Open-Closed Principle 单一职责原则(SRP) - Single Responsibility Principle 里氏替换原则(LSP) - Lisko...
  • 设计模式六大原则

    万次阅读 多人点赞 2019-05-16 17:50:03
    一、单一职责原则(Single Responsibility Principle) 二.开闭原则(Open-Closed Principle, OCP) 三、里氏代换原则(Liskov Substitution Principle, LSP) 四、依赖倒置原则(Dependence Inversion Principle,...
  • java设计模式之三大分类,六大原则

    千次阅读 2017-03-11 11:18:19
    一.设计模式定义(Design Patterns)... 毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样。项目中合理的运用设计模式可以完美的解决
  • 接口隔离原则设计接口要精简单一 迪米特法则:低耦合、高内聚,没必要去了解你所依赖的类或接口的全部,也不需要与你不想了解的类成为直接朋友。 开闭原则:总纲。对外扩展开放,修改关闭!!!
  • 这篇博文算是对《设计模式之禅》的读书笔记。这本书写得非常好,通俗易懂,强烈推荐!另外,也参考了很多其他的资料,包括http://www.runoob.com/design-pattern/design-pattern-tutorial.html以及网上一些博客等,...
  • java设计六大原则

    千次阅读 2018-09-28 09:15:00
    类的设计原则 依赖倒置原则-Dependency Inversion Principle (DIP)  里氏替换原则-Liskov Substitution Principle (LSP)  接口分隔原则-Interface Segregation Principle (ISP)  单一职责原则-Single ...
  • JAVA设计模式六大设计原则

    千次阅读 2018-10-16 16:26:43
    在程序设计中,我们通常要遵循以下六大原则: 单一职责原则 官方定义: 就一个类(接口、结构体、方法等等)而言,有且仅有一个引起它变化的原因。 个人理解: 通俗的来讲做一件事就是专注做一件事,不可以...
  • 3.设计原则6大原则 3.1 开闭原则 3.2 里氏转换原则 3.3 依赖倒转原则 3.4 接口隔离原则 3.5 合成/聚合复用原则 3.6 迪米特原则 1.什么设计模式 软件设计模式(Design pattern),又称设计模式,是一套被反复...
  • Java常见设计模式总结

    万次阅读 多人点赞 2021-09-18 17:18:54
    设计模式是一套经过反复使用的代码设计经验,目的是为了重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式于己于人于系统都...总体来说,设计模式分为三类:5种创建型模式、7种结构型模式、11种行为型模式
  • 设计模式六大原则

    千次阅读 多人点赞 2018-09-06 14:38:04
    关于设计模式的六大设计原则的资料网上很多,但是很多地方解释地都太过于笼统化,我也找了很多资料来看,发现CSDN上有几篇关于设计模式六大原则讲述的比较通俗易懂,因此转载过来。  原作者博客链接:...
  • 本课程针对上述问题,有针对性的进行了升级 (1) 授课方式采用 图解+框架源码分析的方式,让课程生动有趣好理解 (2) 系统全面的讲解了设计模式,包括 设计模式大原则、UML类图-类的六大关系、23种设计模式及其分类,...
  • 类之间的六大关系 1.依赖–只要类中用到了对方,如方法间,变量间,返回值等,就说是依赖关系 2.泛化–继承关系就是泛化关系,泛化关系是依赖的特例,至于为什么你自己想想就知道了 3.实现–实现接口,也是依赖关系...
  • 设计模式六大原则——SOLID

    万次阅读 多人点赞 2018-08-12 20:34:32
    设计模式六大原则有: Single Responsibility Principle:单一职责原则 Open Closed Principle:开闭原则 Liskov Substitution Principle:里氏替换原则 Law of Demeter:迪米特法则 Interface Segregation ...
  • 定义:不要存在多于一个导致类变更的原因。...解决方案:遵循单一职责原则。分别建立两个类T1、T2,使T1完成职责P1功能,T2完成职责P2功能。这样,当修改类T1时,不会使职责P2发生故障风险;同理,当修改T2
  • 24种设计模式介绍与6设计原则
  • 详细介绍设计模式六大原则,有不足之处希望大家多指教。参考《设计模式之禅》

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 41,459
精华内容 16,583
关键字:

java设计模式六大原则

java 订阅