如果地址从电话号码继承，它违反了什么OOP原则？

Question

有一本书谈到拥有一个PhoneNumber类，然后我们将定义一个继承自PhoneNumber的Address类，我曾经说过，我们不能这样做，因为地址不是电话号码，要继承，它必须是一个“is a”关系。例如：狗是一种动物，我们可以让狗继承动物。

但是由于我们必须遵循LSP--Liskov替换原则，“是a”规则实际上不是这里的决定因素，因为正方形“是”矩形（宽度=高度），但是LSP说我们不能定义square类并从Rectangle类继承。我认为，用英语简单的解释是，objectaRect可以响应消息setwidth和height（w，h），但是aSquare不能正确响应它并允许整个程序正确运行。

因此，令人惊讶的是，继承PhoneNumber类的Address类违反了“is a”关系，但它没有违反LSP。那么在形式上，它违反了什么OOP原则？

Answer 1

使用继承或扩展主要有两个原因。

1. 重复使用实施（适用于干式）

我不知道所有的原则，但对于你的情况，它违反了@mpm评论的常识。

因为即使您的代码满足所有原则，它仍然可能是不合适的。换句话说，原则不能涵盖一切。

Answer 2

首先，这确实违反了LSP。

一般来说，您不会期望能够用地址代替电话号码。这是每个人在评论中谈论的“常识”。

OOP理论的要点是，遵循形式化规则将使您的类对变化和奇怪的用例具有健壮性。即使书中的例子没有因为LSP冲突而崩溃，我想如果你试图扩展这个类架构，它也会很快崩溃。因此，为了避免将来类中可能出现的错误，您应该遵循LSP——即使选择不这样做不会立即破坏任何东西。

其次，它违反了ISP（接口隔离原则）。

这说明类中可用的方法集应该是类的对象运行所需的最小值。

如果Address类继承（或可能合理地继承）一组PhoneNumber方法，而这些方法在处理实际街道地址时从未使用过（例如getAreaCode（）方法，这对于房屋地址是未定义的），那么它的接口就不是最小的。

其要点是OOP原则实际上只是指导方针。毫无疑问，我们可以编写一些奇怪的示例代码，这些代码违反了一个坚实的原则，但实际上并没有引入bug。这并不意味着你在逃避规则；这只意味着一旦你试图扩展这个类，你就会遇到更多的bug。