liskov替代原理与界面分离原理的区别

Question

Liskov替代原则（LSP）和界面分离原则（ISP）之间有什么核心区别吗？最终，这两种方法都是为了设计具有通用功能的界面，并在您具有特殊功能时引入新的界面。

Answer 1

LSP管理父类和子类之间的关系（即层次关系）。它告诉您如何实现API。

ISP管理父类和客户端类之间的关系（即生产者/消费者关系）。它告诉您何时实现API。

考虑一个有一百种方法的接口。一个子类可以实现所有100个，而不违反其中任何一个定义的契约，从而满足Liskov替换；但是很难想象每个客户端都需要所有这些方法，所以接口隔离几乎肯定会被违反。

相反，只有一种方法的接口肯定满足接口分离；但是，如果一个实现不遵守这个方法契约，那么就违反了Liskov替换。

另见：LSP与DIP

Answer 2

两者都是坚实的原则

• LSP（Liskov替换）：该原则要求您确保所有子类都具有与父类相同的行为。例如：如果您有一个Device类，它有一个函数callBaba（），该函数获取您父亲的电话号码，然后给他打电话，那么您必须确保Device的所有子类中的callBaba（）方法执行相同的任务。如果Device的任何子类在callBaba（）中有其他行为，则表示您破坏了LSP

违反Liskov原则的代码示例。

class Device {
    func callBaba() {
        print("I will find your father and I will call him")
    }
}

class Calculator: Device {
    override func callBaba() {
      print("Sorry, I don't have this functionality ")
    }
}

解决方案

interface CanCall {
            func callBaba()
        }
        class Device {
            // all basic shared functions here.
        }

        class Calculator: Device {
            // all functions that calculator can do + Device
        }
        class SmartPhone: Device implements CanCall {
            // all smartphone stuff
            func callBaba() {
                print("I will find your father and I will call him")
            }
        }

• ISP（接口隔离）：要求您为不同的职责创建不同的接口，换句话说，不要将不相关的行为分组到一个接口中，如果您已经有一个具有多个职责的接口，那么您就破坏了ISP，并且实现者不需要所有这些东西

这违反了ISP原则，因为它有两种不同的责任

  protocol Animal {
        func fly()
        func eat()
    }

解决方案

protocol Flyable {
    func fly()
}
protocol Feedable {
    func eat()
}

Answer 3

LSP：接收者必须履行其promise的合同。

ISP：呼叫者不应该过分依赖接收器的接口。

适合的地方：如果应用ISP，则只使用接收器完整接口的一部分。但根据LSP的规定，接受者仍然必须尊重这一部分。

如果您未能申请ISP，可能会有违反LSP的诱惑。因为“这个方法不重要，它实际上不会被调用。”