java - 如何编写一个遵循 Liskov Substitution 和其他 SOLID 原则而没有代码味道的 ImmutableMap？

Question

我answered a question重新考虑 ImmutableMap。我建议使用代理模式。

问题是 Map 包含一个 put 方法，它会抛出一个 UnsupportedOperationException。将 Map 的其他实例替换为 ImmutableMap 会破坏 Liskov 替换原则。不仅如此，还需要声明put和putAll【违反了接口(interface)隔离原则】

从技术上讲，没有办法用 ImmutableMap 替换 Map 实例，因为 Map 只是一个接口(interface)。所以我的问题是:

使用 Map 接口(interface)创建一个 ImmutableMap 是否会被视为破坏 LSP，因为 Map 包含一个 put和 putAll 方法？不会将实现 Map 视为“具有不同接口(interface)的替代类”代码味道吗？如何创建一个遵守 LSP 但不包含代码味道的 ImmutableMap？

Answer 1

在我看来，ImmutableMap 应该实现 Map。不实现 Map 是个坏主意，因为有许多方法接受 Map 作为参数并且只以只读方式使用它。我不认为这确实违反了 Liskov 替换原则，因为 Map 的契约(Contract)清楚地表明 put 是一个可选操作。

实现 Map 的类必须实现 put 是不理想的，但替代方案是拥有复杂的接口(interface)层次结构，每个接口(interface)仅包含可能的可选方法。如果有 n 个可选方法，则必须有 2^n 个接口(interface)来覆盖所有组合。 n的值我不知道，但是有一些不明显的可选操作，比如map.entrySet( ).iterator() 支持setValue 操作。如果将此层次结构与实际已经存在的接口(interface)和抽象类的层次结构(包括 AbstractMap、SortedMap、NavigableMap、ConcurrentMap , ConcurrentNavigableMap...) 你会一团糟。

所以这个问题没有完美的答案，但在我看来最好的解决方案是让 ImmutableMap 实现 Map 并确保你编写的每个方法都有一个 Map 作为参数清楚地记录了 Map 必须具有的任何属性，以及如果传递了错误类型的 Map 时抛出的异常。