面向对象基本原则(2)- 里式代换原则与依赖倒置原则

栏目: 后端 · 前端 · 发布时间: 5年前

内容简介:里式代换原则的英文名称是 Liskov Substitution Principle,简称LSP。里式代换原则的英文定义是:通俗点讲,就是只要父类能出现的地方子类就可以出现,而且替换为子类也不会产生任何错误或异常,使用者可能根本就不需要知道是父类还是子类。但是,反过来就不行了,有子类出现的地方,父类未必就能适应。

面向对象基本原则(2)- 里式代换原则与依赖倒置原则

三、里式代换原则

0. 继承的优缺点

在面向对象的语言中,继承是必不可少的、非常优秀的语言机制,它有如下优点:

  • 代码共享,减少创建类的工作量,每个子类都拥有父类的方法和属性。
  • 提高代码的重用性。
  • 子类可以形似父类,但又异于父类,“龙生龙,凤生凤,老鼠生来会打洞”是说子拥有父的“种”,“世界上没有两片完全相同的叶子”是指明子与父的不同。
  • 提高代码的可扩展性,实现父类的方法就可以“为所欲为”了,君不见很多开源框架的扩展接口都是通过继承父类来完成的;
  • 提高产品或项目的开放性。

自然界的所有事物都是优点和缺点并存的,继承的缺点如下:

  • 继承是侵入性的。只要继承,就必须拥有父类的所有属性和方法。
  • 降低代码的灵活性。子类必须拥有父类的属性和方法,让子类自由的世界中多了些约束。
  • 增强了耦合性。当父类的常量、变量和方法被修改时,需要考虑子类的修改,而且在缺乏规范的环境下,这种修改可能带来非常糟糕的结果——大段的代码需要重构。

1. 里式代换原则简介

里式代换原则的英文名称是 Liskov Substitution Principle,简称LSP。

里式代换原则的英文定义是:

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

意思是:所有引用基类的地方必须能透明地使用其子类的对象。

通俗点讲,就是只要父类能出现的地方子类就可以出现,而且替换为子类也不会产生任何错误或异常,使用者可能根本就不需要知道是父类还是子类。但是,反过来就不行了,有子类出现的地方,父类未必就能适应。

2. 里氏替换原则为良好的继承定义了规范

子类必须完全实现父类的方法

/**
 * 枪支抽象类
 * Class AbstractGun
 */
abstract class AbstractGun
{
    public abstract function shoot();
}

/**
 * 手枪
 * Class Handgun
 */
class Handgun extends AbstractGun
{
    public function shoot()
    {
        echo "手枪射击\n";
    }
}

/**
 * 步枪
 * Class Rifle
 */
class Rifle extends AbstractGun
{
    public function shoot()
    {
        echo "步枪射击\n";
    }
}

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

例如想要建立一个玩具手枪类,玩具手枪是不能用来射击的,因此不能实现 AbstractGunshoot() 方法。

子类可以有自己的独有的方法和属性

里氏替换原则可以正着用,但是不能反过来用。

父类能出现的地方子类就可以出现,但是在子类出现的地方,父类未必就可以胜任。

狙击枪类 AUG 继承 Rifle

class AUG extends Rifle
{
    public function shoot()
    {
        echo "AUG射击\n";
    }

    /**
     * 狙击枪特有的行为
     */
    public function zoomOut()
    {
        echo "通过望远镜察看敌人...\n";
    }
}

创建士兵类 Soldier

class Soldier
{
    /** @var AbstractGun */
    private $_gun;

    public function setGun(AbstractGun $gun)
    {
        $this->_gun = $gun;
    }

    public function killEnemy()
    {
        echo "士兵开始杀敌了\n";

        $this->_gun->shoot();
    }
}

实例化一个士兵,让他使用步枪杀人

// 产生三毛这个士兵
$sanMao = new Soldier();
// 给三毛一支步枪
$sanMao->setGun(new Rifle());
$sanMao->killEnemy();
士兵开始杀敌了
步枪射击

根据里氏代换原则,父类能出现的地方子类就可以出现,给士兵一把狙击枪试试

//产生三毛这个士兵
$sanMao = new Soldier();
//给三毛一支狙击枪
$sanMao->setGun(new AUG());
$sanMao->killEnemy();
士兵开始杀敌了
AUG射击

可见,使用子类(AUG)代替父类(Rifle)完全没有问题。

创建狙击手类 Snipper

class Snipper
{
    /** @var AUG */
    private $_gun;

    public function setGun(AUG $gun)
    {
        $this->_gun = $gun;
    }

    public function killEnemy()
    {
        echo "狙击手开始杀敌了\n";

        //首先看看敌人的情况
        $this->_gun->zoomOut();
        //开始射击
        $this->_gun->shoot();
    }
}

实例化一个狙击手,让他使用狙击枪杀人

// 产生三毛这个狙击手
$sanMao = new Snipper();
// 给三毛一支狙击枪
$sanMao->setGun(new AUG());
$sanMao->killEnemy();
狙击手开始杀敌了
通过望远镜察看敌人...
AUG射击

但是,如果给狙击手一支步枪,狙击手反而用不了了,因为步枪没有用来观察敌人的望远镜

// 产生三毛这个狙击手
$sanMao = new Snipper();
// 给三毛一支步枪
$sanMao->setGun(new Rifle());
$sanMao->killEnemy();
PHP Fatal error:  Uncaught TypeError: Argument 1 passed to Snipper::setGun() must be an instance of AUG, instance of Rifle given

3. 最佳实践

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

把子类当做父类使用,子类的“个性”被抹杀 -- 委屈了点;

把子类单独作为一个业务来使用,则会让代码间的耦合关系变得扑朔迷离 -- 缺乏类替换的标准。

四、依赖倒置原则

1. 依赖倒置原则简介

依赖倒置原则的英文名称是 Dependence Inversion Principle,简称DIP。

依赖倒置原则的英文定义是:

High level modules should not depend upon low level modules.Both should depend uponabstractions.Abstractions should not depend upon details.Details should depend upon abstractions.

翻译过来,包含以下含义:

  • 高层模块不应该依赖低层模块,两者都应该依赖其抽象。
  • 抽象不应该依赖细节。
  • 细节应该依赖抽象。

什么是高层模块?什么是低层模块?

每一个逻辑的实现都是由原子逻辑组成的,不可分割的原子逻辑就是低层模块,原子逻辑的再组装就是高层模块。

什么是抽象?什么又是细节?

抽象就是指接口或抽象类,两者都是不能直接被实例化的。

细节就是实现类,实现接口或继承抽象类而产生的类就是细节,其特点就是可以直接被实例化。

抽象是对实现的约束,对依赖者而言,也是一种规则,不仅仅约束自己,还同时约束自己与外部的关系,其目的是保证所有的细节不脱离规则的范畴,确保约束双方按照既定的规则(抽象)共同发展,只要抽象这根基线在,细节就脱离不了这个圈圈。

什么是“倒置”?

先说“正置”是什么意思,依赖正置就是类间的依赖是实实在在的实现类间的依赖,也就是面

向实现编程,这也是正常人的思维方式,我要开奔驰车就依赖奔驰车,我要使用笔记本电脑

就直接依赖笔记本电脑,而编写程序需要的是对现实世界的事物进行抽象,抽象的结果就是

有了抽象类和接口,然后我们根据系统设计的需要产生了抽象间的依赖,代替了人们传统思

维中的事物间的依赖,“倒置”就是从这里产生的。

2. 面向接口编程

面向接口编程 OOD(Object-Oriented Design),是面向对象设计的精髓之一。

依赖倒置原则的表现其实就是面向接口编程。

  • 模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生的;
  • 接口或抽象类不依赖于实现类;
  • 实现类依赖接口或抽象类。

3. 依赖倒置原则的优点

  • 减少类间的耦合性,提高系统的稳定性。
  • 降低并行开发引起的风险。
  • 提高代码的可读性和可维护性。

4. 依赖的三种写法

构造函数传递依赖对象

在类中通过构造函数声明依赖对象,按照依赖注入的说法,这种方式叫做构造函数注入。

interface ICar
{
    public function run();
}

interface IDriver
{
    public function drive();
}

class Driver implements IDriver
{
    private $_car;

    public function __construct(ICar $car)
    {
        $this->_car = $car;
    }

    public function drive()
    {
        $this->_car->run();
    }
}

Setter方法传递依赖对象

在抽象类中设置Setter方法声明依赖关系,依照依赖注入的说法,这是Setter依赖注入。

interface ICar
{
    public function run();
}

interface IDriver
{
    public function setCar(ICar $car);

    public function drive();
}

class Driver implements IDriver
{
    private $_car;

    public function setCar(ICar $car)
    {
        $this->_car = $car;
    }

    public function drive()
    {
        $this->_car->run();
    }
}

接口声明依赖对象

在接口的构造方法中声明依赖对象,这种方法叫做接口注入。

interface ICar
{
    public function run();
}

interface IDriver
{
    public function __construct(ICar $car);

    public function drive();
}

5. 最佳实践

依赖倒置原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立,不互相影响,实现模块间的松耦合。需要遵循以下的几个规则。

每个类尽量都有接口或抽象类,或者抽象类和接口两者都具备

这是依赖倒置的基本要求,接口和抽象类都是属于抽象的,有了抽象才可能依赖倒置。

任何类都不应该从具体类派生

如果一个项目处于开发状态,确实不应该有从具体类派生出子类的情况,但这也不是绝对的,因为人都是会犯错误的,有时设计缺陷是在所难免的,因此一些情况下的继承都是可以忍受的。

特别是项目维护阶段,维护工作基本上都是进行扩展开发,修复行为。通过一个继承关系,覆写一个方法就可以修正一个很大的Bug,何必去继承最高的基类呢?(当然这种情况尽量发生在不甚了解父类或者无法获得父类代码的情况下。)

尽量不要覆写基类的方法

如果基类是一个抽象类,而且这个方法已经实现了,子类尽量不要覆写。

类间依赖的是抽象,覆写了抽象方法,对依赖的稳定性会产生一定的影响。

结合里氏替换原则使用

接口负责定义public属性和方法,并且声明与其他对象的依赖关系。

抽象类负责公共构造部分的实现,实现类准确的实现业务逻辑,同时在适当的时候对父类进行细化。

6. Show me the code

汽车接口 ICar 和司机接口 IDriver

interface ICar
{
    public function run();
}

interface IDriver
{
    public function __construct(ICar $car);

    public function drive();
}

Driver 类实现 IDriver 接口

class Driver implements IDriver
{
    private $_car;

    public function __construct(ICar $car)
    {
        $this->_car = $car;
    }

    public function drive()
    {
        echo "老司机准备上路\n";
        $this->_car->run();
    }
}

BenzBMW 分别实现 ICar 接口

class Benz implements ICar
{
    public function run()
    {
        echo "奔驰汽车开始起步\n";
    }
}

class BMW implements ICar
{
    public function run()
    {
        echo "宝马汽车开始起步\n";
    }
}

司机张三开奔驰车上路

// 制造一台奔驰车
$benz = new Benz();
// 创建一个司机张三,把奔驰车给张三
$zhangSan = new Driver($benz);
// 张三开奔驰车
$zhangSan->drive();
老司机准备上路
奔驰汽车开始起步

司机李四开宝马车上路

// 制造一台宝马车
$bmw = new BMW();
// 创建一个司机李四,把宝马车给李四
$lisi = new Driver($bmw);
// 李四开宝马车
$lisi->drive();
老司机准备上路
宝马汽车开始起步

参考文献:《设计模式之禅》


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

程序与民主

程序与民主

皮罗·克拉玛德雷 / 翟小波 / 高等教育 / 2005-3 / 8.20元

《程序与民主》是意大利著名政治学家、法学家皮罗·克拉玛德雷(Pierocalamandrei)(1889-1956)讨论现代诉讼程序的著作。该书篇幅虽小,但影响甚大。国内对该著者及其作品的介绍较少,倒是其弟子卡佩莱蒂的著作已有中文译本:《当事人基本程序保障权与未来的民事诉讼》,徐昕译,法律出版社2000年版。《程序与民主》一书,并非平行地讨论程序和民主,而是从程序的视角讨论民主。这里的民主,也不是......一起来看看 《程序与民主》 这本书的介绍吧!

随机密码生成器
随机密码生成器

多种字符组合密码

URL 编码/解码
URL 编码/解码

URL 编码/解码

HEX CMYK 转换工具
HEX CMYK 转换工具

HEX CMYK 互转工具