一：里式替换原则
面向对象中继承的一些思考
继承有这样一层含义：
父类中凡是已经实现的方法，实际上是在设定规范和契约，虽然它不强制要求所有子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。
继承在给程序设计带来便利的同时，也带来了弊端，比如使用继承会给程序带来入侵性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障。
核心内容：
继承必须确保超类所拥有的性质在子类中仍然成立，也就是说，子类中不要去重写父类中已经实现的方法，所有引用基类的地方必须能透明的使用其子类对象
里式替换原则增加了两个类的耦合性，在适当的情况下，可以通过聚合，组合，依赖来解决问题
基本原则
- 里氏替换原则（Liskov Substitution Principle）在1988年，由麻省理工学院的一位姓里的女士提出的。指的是任何基类可以出现的地方，子类一定可以出现。
- 核心内容：继承必须确保超类所拥有的性质在子类中仍然成立，也就是说在继承时，子类中不要去重写父类中已实现的方法。
- 里氏替换原则告诉我们，继承实际上让两个类耦合性增加了，在适当的情况下，可以通过聚合，组合，依赖来解决问题。
举个例子
class HXComputer {
public:
int calculate(int num1, int num2) {
return num1 + num2;
}
};
class NotebookComputer : HXComputer {
public:
int calculate(int num1, int num2) {
return num1 - num2;
}
int notebookCalculate(int num1, int num2, int num3){
return calculate(num1,num2) * num3;
}
};
int main(int argc, const char * argv[]) {
HXComputer computer;
std::cout << computer.calculate(1,2) << std::endl;
NotebookComputer notebookCalculate;
std::cout << notebookCalculate.notebookCalculate(1,2,3) << std::endl;
return 0;
}
代码中，HXComputer 实现了 calculate 函数，作用是求两个数的和，NotebookComputer 继承了 HXComputer， notebookCalculate 的作用是求 num1 和 num2 和的 num3 倍。
已知 NotebookComputer 的父类已经实现了求和函数，所以直接使用，但是输出结果却不对
是因为子类 NotebookComputer 无意间重写了父类的 calculate 函数
改进方案
- 改继承为依赖、组合来解决问题
- 抽取两个类的共有部分到父类 Electronics
- HXComputer 和 NotebookComputer 之间的关系不再是继承，而是依赖
class Electronics {
// 共有属性
};
class HXComputer : Electronics {
public:
int calculate(int num1, int num2) {
return num1 + num2;
}
};
class NotebookComputer : Electronics {
private:
HXComputer computer;
public:
int calculate(int num1, int num2) {
return num1 - num2;
}
int notebookCalculate(int num1, int num2, int num3){
return computer.calculate(num1,num2) * num3;
}
};
int main(int argc, const char * argv[]) {
HXComputer computer;
std::cout << computer.calculate(1,2) << std::endl;
NotebookComputer notebookCalculate;
std::cout << notebookCalculate.notebookCalculate(1,2,3) << std::endl;
return 0;
}
二：依赖倒置原则
首先从一个很简单的例子谈起：
游戏中用角色打怪的场景，角色可以用剑攻击怪物，很容易写出如下的代码：
// 剑
class Sword {
public:
int attack() {
std::cout << "用剑攻击\n";
return 0;
}
};
// 角色
class Role {
public:
Sword sword;
int attackMonster() {
sword.attack();
return 0;
}
};
int main(int argc, const char * argv[]) {
Role role;
role.attackMonster();
return 0;
}
输出：
用剑攻击
目前看来非常的 ok
但是如果鸟枪换炮，不用剑攻击了，改用抢射击
那么就要修改 Role 中的逻辑
不断的更新装备，就要不断的修改
这显然违背了开闭原则，扩展性极差
这时候考到武器的共性就是可攻击
所以我们抽象出一个攻击接口，让所有的武器来实现这个接口
让更换武器的时候，Role 不需要感知是什么武器
只需要发起攻击指令就可
// 抽象类
class Weapon {
public:
virtual int attack() = 0;
};
// 剑
class Sword : public Weapon {
public:
int attack() {
std::cout << "用剑攻击\n";
return 0;
}
};
// 抢
class Gun : public Weapon {
public:
int attack() {
std::cout << "用抢射击\n";
return 0;
}
};
class Role {
public:
Weapon *weapon;
int attackMonster() {
weapon->attack();
return 0;
}
};
int main(int argc, const char * argv[]) {
Sword sword;
Gun gun;
Role role;
role.weapon = &sword;
// role.weapon = &gun;
role.attackMonster();
return 0;
}
这样无论 Role 拿到的是什么武器，都是采用 attackMonster 的方式发起攻击
Role 无需关心其他细节
这就是依赖倒置原则：
- 高层模块不应该依赖低层模块，两者都应该依赖抽象
- 抽象不应该依赖细节，细节应该依赖抽象
在实际的的项目开发中，通常会将业务逻辑划分成为独立模块
高层模块的功能是通过许多底层模块的功能实现的
两者直接依赖将会使得两者之间产生强耦合
任何一个模块的改动都会引起另一个模块的改动
为了解决这个问题，会遵从依赖倒置原则
让相互依赖的模块都依赖于抽象
高层模块依赖抽象来提供服务，底层模块依赖抽象来实现功能
就形成了依赖倒置（依赖反转）