是数组。是否列出违反Liskov替代原则的情况？[副本]

Question

数组。asList（…） 返回数组周围的列表包装。此包装具有固定大小，并直接由数组支持，因此，对add（）或其他试图修改列表的函数的调用将引发UnsupportedOperationException。

开发人员经常对此感到惊讶，stackoverflow中的问题就是明证。

然而，列表接口有一个add（）方法，根据Liskov替换原则（LSP），它应该对列表的所有派生器都能正常工作

是数组返回的类型。asList（）违反Liskov替换原则的示例？




Answer 1

如果你从非常专业的角度来考虑，那么这当然是一种违反。LSP指出，坏的设计是继承类不能使用超类方法的设计。但是Java并不总是关心违规行为。正如您所建议的那样，这常常会让开发人员感到困惑。add（）方法就是一个例子，remove（）也是一个例子。这两种方法都适用于不可变列表，并且不能更改。好的是，至少抛出了一个异常。

进一步阅读：http://c2.com/cgi/wiki?UnmodifiableListIsStupidAndItBreaksLsp

Answer 2

我认为这并没有违反LSP。

LSP说，实现给定接口的类的所有实例都可以互换使用。

列表的文档。add（和其他变异方法）明确指出，该方法的实现可能会引发不支持操作异常。

投掷

UnsupportedOperationException-如果此列表不支持添加操作

因此，如果要对来自未知源的List实例调用此方法，则需要处理add抛出Unsupport tedoperationExc0019的情况。

如果不这样做，则说明您没有正确使用API。

这并不是说我喜欢这个设计。我认为，试图调用该方法是检测实例上不支持任何给定方法的唯一方法这一事实是垃圾。我的意思是，见鬼，给我们一个isAddSupported（）方法（或类似方法）。

我只是不认为以下记录的行为会违反LSP。

Answer 3

严格地说，确实如此，因为LSP没有可选接口成员的概念：方法要么是接口的一部分，要么不是接口的一部分。

然而，当Java类库将某些接口方法指定为可选时，它显式地允许违反LSP<代码>列表

本质上，Java库的设计者走了一条捷径：他们没有为可变列表（扩展只读列表）创建单独的接口，而是将操作指定为“可选”。此外，它们还没有为您提供一种方法来测试list实例的只读性，因此您唯一的选择是捕获运行时异常，这是一个非常糟糕的想法。这相当于您必须跟踪列表的来源，并且只有在100%确定列表来源时才执行可选操作。