乐趣区

关于java:深入浅出设计模式里氏替换原则

1. 里氏替换准则介绍

2. 用代码演示里氏替换准则

3. 总结

1. 里氏替换准则介绍

定义
1)如果对每一个类型为 T1 的对象 o1,都有类型为 T2 的对象 o2,使得以 T1 定义的所有程序 P 在所有的对象 o1 都代换成 o2 时,程序 P 的行为没有发生变化,那么类型 T2 是类型 T1 的子类型。
2)所有援用基类的中央必须能通明地应用其子类的对象。

咱们看到这里时可能看不太懂,简而言之就是当应用继承的时候,比方类 B 继承类 A,除了增加新的办法实现新增性能 P2 外,尽量不要重写父类 A 的办法,也不要重载父类 A 的办法。

问题形容 :我置信咱们都用过 ORM 框架,比方 mybatis,jpa 等等。这里咱们拿 jpa 举例,假如 jpa 基类中,有一个封装好的 findAll() 办法,是获取所有的数据,然而咱们在子类(本人的 service)中,给它重写成了只获取以后操作者的所有数据,这样乍一看没什么问题,然而如果先有人写好了应用 findAll()办法并且稳固运行的代码,被后续的人批改了业务逻辑,就会造成异样。

解决办法
子类能够扩大父类的性能,但不能扭转父类原有的性能,不要去重写,重载父类的性能。

2. 用代码演示依赖倒转准则

假如咱们当初有这么一个办法:

public interface JpaRepository {
// 默认是取出所有数据
List<T> findAll();}

假如 A 共事应用了上述办法进行开发,并且代码曾经稳固运行了,然而 B 共事在本人的代码里笼罩了这个办法:

public interface UserRepository extends JpaRepository {

    // 只查问状态不被禁用的用户
    @Query(value = "select * from user where status = 1")
    List<User> findAll();}

这就会导致原来运行好的程序呈现了 bug,重大点的可能会报空指针异样或者逻辑谬误等等问题。

3. 总结

当应用继承时,遵循里氏替换准则。除了增加新的办法实现性能外,不要去重写父类 A 的办法,也不要重载父类 A 的办法。

继承尽管好用,然而用不好就会呈现大量问题,并且在写代码的时候要思考到,批改父类后,是不是所有子类的性能会受到影响。

退出移动版