我最近正在阅读Java Concurrency in Practice，并且第一次接触Collections.unmodifiableMap(...)方法。该方法在现有的Map周围创建一个只读包装，并且任何修改返回的Map的尝试都会（根据Javadocs）导致抛出UnsupportedOperationException。其他集合类也存在类似的方法。
这让我非常担心，因为unmodifiableMap()仍返回Map，但不支持所有相关方法。它还会在写操作中引发异常，这意味着它不能替代大多数应用程序中的“适当” Map。
我是一名学生，对我认识到设计缺陷的能力还没有信心，但是这些分别违反了Interface segregation和Liskov substitution原则吗？
实现可能会选择不支持其所有方法的Map接口文档，这会使Collections.unmodifiableMap返回一个满足接口协定的实现。
尽管接口以这种方式将其方法的实现变为“可选”是不寻常的，但这是一种设计折衷方案，在实践中效果很好。大多数集合应该只写一次，然后一次又一次地读取，因此修改地图的代码通常是创建它并知道其可变的代码。
[关于ISP，鲍勃·马丁可能会考虑Collections.unmodifiableMap()与他的stack class example一样犯规。它将客户端暴露给他们不需要的接口，实际上是不能使用的。
如上所述，接口文档满足了LSP的要求。