我最近在阅读Java Concurrency in Practice，第一次接触到Collections.unmodifiableMap(...) 方法。该方法围绕现有 Map 创建一个只读包装器，任何修改返回的 Map 的尝试都将(根据 Javadocs)导致抛出 UnsupportedOperationException。其他集合类也存在类似的方法。
这让我很担心，因为 unmodifiableMap() 仍然返回一个 Map，但不支持所有相关方法。事实上，它还会在写操作时抛出异常，这意味着它无法在大多数应用程序中替代“适当的”Map。
我是一名学生，对自己识别设计缺陷的能力还没有信心，但这些是否分别违反了接口(interface)隔离和里氏替换原则？
最佳答案
实现可能选择不支持其所有方法的 Map 接口(interface)文档，这使得 Collections.unmodifiableMap 返回满足接口(interface)契约的实现。
虽然接口(interface)以这种方式“可选”实现其方法并不常见，但这是一种在实践中工作得很好的设计折衷。大多数集合应该只写入一次，然后一次又一次地读取，因此修改映射的代码通常是创建它的代码并且知道它是可变的。
关于java - Collections.unmodifiableMap(和其他)是否违反了 SOLID 原则？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/62420172/