1700455333
1700455334
private ICar car；
1700455335
1700455336
public void setCar（ICar car）{
1700455337
1700455338
this.car=car；
1700455339
1700455340
}
1700455341
1700455342
//司机的主要职责就是驾驶汽车
1700455343
1700455344
public void drive（）{
1700455345
1700455346
this.car.run（）；
1700455347
1700455348
}
1700455349
1700455350
}
1700455351
1700455352
3.接口声明依赖对象
1700455353
1700455354
在接口的方法中声明依赖对象，3.2节的例子就采用了接口声明依赖的方式，该方法也叫做接口注入。
1700455355
1700455356
1700455357
1700455358
1700455360
设计模式之禅 3.4 最佳实践
1700455361
1700455362
依赖倒置原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合，我们怎么在项目中使用这个规则呢？只要遵循以下的几个规则就可以：
1700455363
1700455364
❑每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备
1700455365
1700455366
这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置。
1700455367
1700455368
❑变量的表面类型尽量是接口或者是抽象类
1700455369
1700455370
很多书上说变量的类型一定要是接口或者是抽象类，这个有点绝对化了，比如一个工具类，xxxUtils一般是不需要接口或是抽象类的。还有，如果你要使用类的clone方法，就必须使用实现类，这个是JDK提供的一个规范。
1700455371
1700455372
❑任何类都不应该从具体类派生
1700455373
1700455374
如果一个项目处于开发状态，确实不应该有从具体类派生出子类的情况，但这也不是绝对的，因为人都是会犯错误的，有时设计缺陷是在所难免的，因此只要不超过两层的继承都是可以忍受的。特别是负责项目维护的同志，基本上可以不考虑这个规则，为什么？维护工作基本上都是进行扩展开发，修复行为，通过一个继承关系，覆写一个方法就可以修正一个很大的Bug，何必去继承最高的基类呢？（当然这种情况尽量发生在不甚了解父类或者无法获得父类代码的情况下。）
1700455375
1700455376
❑尽量不要覆写基类的方法
1700455377
1700455378
如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要覆写。类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会产生一定的影响。
1700455379
1700455380
❑结合里氏替换原则使用
1700455381
1700455382
在第2章中我们讲解了里氏替换原则，父类出现的地方子类就能出现，再结合本章的讲解，我们可以得出这样一个通俗的规则：接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。
[
上一页 ]
[ :1.700455333e+09 ]
[
下一页 ]