PHP衣食父母系列-依赖倒置

老司机换新车
本文通过一个生动的例子介绍了软件设计中的开闭原则。假设一个习惯驾驶奔驰的司机需要驾驶宝马,如何仅通过客户端代码的添加就能实现这一变化,而不改变司机(Driver)的行为。通过定义通用接口实现了对不同品牌车辆的支持。
// 如果开惯了奔驰的司机,让他开宝马?(咱不能因为换车咯,就把老司机也给开了,那至少不道德对不?)
// 如果修改Driver(比如让司机重回架校学车)了,这就违反了开闭原则了,怎么能只在Client添加代码就让咱的老司机也会开宝马了呢?

interface ICar{
    
    //定义一个汽车接口
    public function run();
}

class BMW implements ICar{

    public function run(){
    
        return "BMW is runing !!!";
    }
}

class Benz implements ICar{

    public function run(){
    
        return "Benz is runing !!!";
    }

}

interface IDriver{
    
    //定义一个司机接口,以防以后有A照,B照,C照的
    public function drive(ICar $car);
}

class Driver implements IDriver{

    public function drive(ICar $car){
    
        echo "<br>" . $car -> run();
    }

}

class Client{

    public static function doing(){
    
        $driver = new Driver();

        $driver -> drive( new BMW() ); //开宝马

        $driver -> drive( new Benz() ); //开奔驰
         //   
            
    }

}

Client :: doing();

//我就不写“?>”闭合符号!
SOLID原则中的依赖倒置原则(Dependency Inversion Principle,DIP)是指高层模块不应该依赖底层模块,二者都应该依赖于抽象接口;抽象接口不应该依赖于具体实现,而具体实现应该依赖于抽象接口。 简单来说,DIP原则就是通过接口来解耦高层模块和底层模块之间的依赖关系,使得系统更加灵活、可维护、可扩展。在设计和开发过程中,我们应该遵循DIP原则,尽可能使用接口或抽象类来定义模块之间的依赖关系,而不是直接依赖具体实现类。 举个例子,假设我们正在开发一个电商系统。我们有一个OrderService类,它依赖于一个底层模块的OrderDao类来实现订单数据的持久化。如果我们直接在OrderService类中实例化OrderDao对象,那么OrderService类就与OrderDao类紧密耦合,如果我们需要更换一种不同的数据持久化方案,那么就需要修改OrderService类的代码,违反了开闭原则(Open Close Principle,OCP)。 为了遵循DIP原则,我们可以先定义一个抽象的OrderDao接口,然后让OrderService类依赖于OrderDao接口。底层模块的具体实现类可以实现OrderDao接口,这样就可以实现数据持久化的功能,同时也可以轻松地更换不同的数据持久化方案,不需要修改OrderService类的代码。 总之,DIP原则是设计模式中非常重要的原则之一,它可以帮助我们构建更加灵活、可维护、可扩展的系统。在实际开发中,我们应该尽可能地遵循DIP原则,使用接口或抽象类来定义模块之间的依赖关系,降低模块之间的耦合度,提高系统的可维护性和可扩展性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值