面向对象设计基本原则

引言

  在软件开发过程中,随着系统复杂度的增加,业务的变更,程序员面临着耦合性,内聚性,可维护性,可扩展性,可重用性的挑战。而良好的设计模式就可以解决此类问题。设计模式是包含了面向对象的精髓,熟练掌握面向对象设计/分析是掌握设计模式的基础。可以帮助我们考虑代码结构,使代码易于维护、易于扩展、易于阅读。

  那么设计模式本身也是有自己需要遵守的原则,也是各种设计模式的基础。那么设计模式有常用的七大原则。

 

 

设计模式有常用的七大原则

  1.单一职责(Single Responsibility Principle):一个类,只做一件事并且做好。

    特点:

      1)一个类只负责一件事,可以降低类的复杂性。

      2)提高类的可读性,可维护性就提高了。

      3)降低变更引起可能出现的风险,如果接口的单一职责做得好,一个接口修改只对应的实现类有影响,对其他的接口无影响,这对系统的扩展性、维护性都有非常大的帮助。。

    

    例如我们 web开发中常用的 MVC 开发模式就是单一职责原则的体现。

      1)Model 层提供数据。

      2)View 层专注于前端视图的展示。

      3)Controller层专注业务逻辑。

 

  2.接口分离原则(Interface Segregation Principle):为各个类建立他们所需要的专门的接口。把一个接口切分为多个接口,把一个大的职责切分为小职责以及这些职责之间的协作交互。比如一个客户端不应该依赖它不需要的接口,即一个类对另外一个类的依赖应该建立在最小接口上。

      1).  接口要尽量小。

         这是接口隔离原则的核心定义,不出现臃肿的接口(Fat Interface),但是“小”是有限度的,首先就是不能违反单一职责原则。
         根据接口隔离原则拆分接口时,首先必须满足单一职责原则。

      2).  接口要高内聚。

        高内聚就是要提高接口、类、模块的处理能力,减少对外的交互。
        具体到接口隔离原则就是,要求在接口中尽量少公布public方法,接口是对外的承诺,承诺地越少对系统开发越有利,变更的风险也就越少,同时也有利于降低成本。

      3).  定制服务。
        定制服务就是单独为一个个体提供优良的服务。

      4). 接口设计是有限度的。
        接口的设计粒度越小,系统越灵活,这是不争的事实。但是,灵活的同时也带来了结构的复杂化,开发难度增加,可维护性降低,这不是一个项目或产品所期望看到的,所以接口设计一定要注意适度,这个度只能根据经验和常识判断,没有一个固化或可测量的标准。

 

      单一职责和接口分离原则的共同点:

      1)都是提高类的内聚性,降低耦合性。

     单一职责和接口分离原则的不同点:

    

  3.开放封闭原则(Open Close Principle:一个类应该是对扩展是开放的,对类的内部修改是封闭的,不应该通过修改来增加类的功能,而是通过扩展来增加功能。

    比如一个类中有两个功能,现在要增加第三个功能,那么这个新增加的功能不能对另外两个功能有影响。

    开放封闭原则是面向对象中最重要的原则,相当于一个总纲领。

 

  4.依赖倒置原则(Dependency Inversion Principle)

    

    这条原则说明两个基本的要点:

      1)高阶的模块不应该依赖低阶的模块,它们都应该依赖于抽象

      2)抽象不应该依赖于实现,实现应该依赖于抽象

      一个类不应该强依赖另外一个类,每个类对于另外一个类都是可以替换的。高层模块不需要依赖底层的模块。

      比如A类和B类,A类需要B类的相关功能,A类不应该在其内部中直接调用B类,而是应该使用依赖注入的方式通过注入的方式,来将B类的对象注入到A类中,这样B类对于A类来说是可以替换的。高层模块也不应该依赖低层模块,二者都应该依赖其抽象,都是面向接口编程,而不是面向具体实现。接口一般都是稳定的。使用接口或者抽象类可以更好的制定一些规范和契约,而不去涉及具体的操作,具体的实现交给具体的类来完成。

  5.里氏替换原则(Liskov Substitution Principle):继承必须确保父类中所拥有的所有性质在子类中依然成立。就是子类可以扩展父类的功能,子类尽量添加新的方法不要改变父类原有的功能,程序中对于实例化对象的子类型,不需要修改代码,可以直接进行替换。

    有个著名的说法:正方形不是长方形。

          Liskov于1987年提出了一个关于继承的原则 “Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.”(继承必须确保超类所拥有的性质在子类中仍然成立)。

    就是说,当一个子类的实例应该能够替换任何其父类的实例时,它们之间才具有is-A关系。

  6.合成复用原则(Composite Reuse Principle,CRP)尽量使用组合或者聚合等关联关系来实现,其次在考虑使用继承关系来实现。

    组合是Has-A的关系,继承是Is-A关系。“Is-A”是严格的分类学意义上的定义,意思是一个类是另以个类的“一种”。而“Has-A”表示某一个角色具有某一项责任。比如狗和动物是继承关系,狗不能和动物用组合,因为狗不是动物组成的。

    合成复用原则和里氏替换原则是相辅相成的,如果要使用继承关系,则必须严格遵循里氏替换原则。

    通常类的复用分为继承复用和合成复用两种,继承复用虽然有简单和易实现的优点,但它也存在以下缺点:

      1)继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类,父类对子类是透明的,所以这种复用又称为“白箱”复用。

      2)子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化,这不利于类的扩展与维护。

      3)它限制了复用的灵活性。从父类继承而来的实现是静态的,在编译时已经定义,所以在运行时不可能发生变化。


    
采用组合或聚合复用时,可以将已有对象纳入新对象中,使之成为新对象的一部分,新对象可以调用已有对象的功能,它有以下优点:

      1)它维持了类的封装性。因为成分对象的内部细节是新对象看不见的,所以这种复用又称为“黑箱”复用。

      2)新旧类之间的耦合度低。这种复用所需的依赖较少,新对象存取成分对象的唯一方法是通过成分对象的接口。

      3)复用的灵活性高。这种复用可以在运行时动态进行,新对象可以动态地引用与成分对象类型相同的对象。

 

 

  7.迪米特法则(Law of Demeter)又称之为最少知识原则(Least Knowledge Principle)。

   迪米特法则的定义是:只与你的直接朋友交谈,不跟“陌生人”说话(Talk only to your immediate friends and not to strangers)。其含义是:如果两个类之间无须直接通信,那么就不应当发生直接的相互调用,可以通过第三方转发该调用。其目的是降低类之间的耦合度,尽量减少对其他类的依赖,提高模块的相对独立性。
  

  通俗的来讲,就是描述一个类对自己依赖的类知道的越少越好,无需关心是怎么实现的,对于被依赖的类来说,无论逻辑多么复杂,都尽量地的将逻辑封装在类的内部,对外除了提供的public方法,不对外泄漏任何信息。迪米特法则还有一个更简单的定义:只与直接的朋友通信。首先来解释一下什么是直接的朋友:迪米特法则中的“朋友”是指:当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等,这些对象同当前对象存在关联、聚合或组合关系,可以直接访问这些对象的方法。只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系。耦合的方式很多,依赖、关联、组合、聚合等。其中,我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友,而出现在局部变量中的类则不是直接的朋友。也就是说,陌生的类最好不要作为局部变量的形式出现在类的内部。 所以一般应用迪米特法则设计的类都有一些特点,减少暴露类成员,类本身不能被改变,降低对类的访问权限等。

  在《程序员修炼之道》这本书中有提到。

  设计模式的门面模式(Facade)和中介者模式(Mediator),都是迪米特法则应用的例子。

  迪米特法则优点:

    1)降低了类之间的耦合度,提高了模块的相对独立性。

    2)由于亲合度降低,从而提高了类的可复用性和系统的扩展性。

     迪米特法则缺点:

    1)过分的使用迪米特原则,会产生大量这样的中间类和传递类,导致系统复杂度变大。

  使用原则:

    使用迪米特原则时候要权衡好,保证系统架构的清晰。

其他的设计原则

  1.配置化:尽可能的使用配置,而不要使用硬编码的方式。比如像一些数据库参数及常量,应该放到配置文件中。

    2.面向接口编程:只需要关心接口,不需要关心具体的实现。

    3.DRY(Don't Repeat Yourself )避免重复代码抽取重复的代码封装成一个函数或者类方法,保持里面的逻辑一致,可以被其他使用者调用。

    4.组合优于继承(Com­po­si­tion over Inher­i­tance): 这里有篇老外写的文章This is why you need Composition over Inheritance

posted @ 2019-08-04 01:21  songguojun  阅读(1140)  评论(0编辑  收藏  举报