通过添加更多逻辑来打破 Liskov 替换原则答案

【问题标题】：Breaking Liskov substitution principle by adding more logic通过添加更多逻辑来打破 Liskov 替换原则
【发布时间】：2020-06-13 10:18:07
【问题描述】：

我有一个类：用户和客户。 User 有基本的 getter、setter 名称、电子邮件和客户需要的东西，但 Customer 有像 getOrders() 这样的方法，User 类的其他子类没有，比如 ProjectManager。这是否意味着 Customer 不应扩展 User 并拥有自己的 first_name、last_name、email... 属性？

还是说Customer类可以扩展User类，通过订单方法和客户相关方法扩展逻辑？

【问题讨论】：

标签： java oop liskov-substitution-principle

【解决方案1】：

或者说Customer类扩展User类可以吗

是的，应该就是这样。原则告诉我们，客户（或用户的任何其他子类）必须能够在需要用户的任何地方使用。同样的情况不需要反过来发生，子类也不必相互替代。

【讨论】：

问题是“这是否意味着客户不应该扩展用户……或者客户类可以扩展用户类……？”简而言之，“延长或不延长”。你回答“是”。是的，选择什么？我建议你改进你的答案。

【解决方案2】：

您应该从面向对象的角度提出问题，这有意义吗？客户是用户，还是客户有时不是用户？还是所有用户都是客户？首先从逻辑角度考虑您的对象模型。不要试图通过放置逻辑上不存在的连接来人为地变得聪明。

我不知道您在哪个域中使用它。用户可能是使用您的产品的东西，客户可能是从您那里购买产品并将其提供给用户的实体。如果是这样，就没有 IS-A 关系，只有 HAS-A 关系。所以他们不应该继承。然后复制相当多的字段的事实是“好的”。你可以通过拥有一个Person 类来解决这个问题，两者都继承自该类

【讨论】：