java - Java 中的类层次结构 - 什么有意义与更容易实现

Question

我有以下类/接口(interface)层次结构:

+ interface Resource
|-- + abstract class AbstractResource
|   |-- + class ...
|
|-- + interface ConcurrentResource
    |-- + abstract class AbstractConcurrentResource
        |-- + class ...

地点:

public interface Resource {
    /* Some methods here */
}

---

public interface ConcurrentResource extends Resource {
    void acquireFor(AccessMode mode);
    void release();
    /* ... */
}

---

这对我来说听起来合乎逻辑。 Resource , 本身可能有也可能没有意识到并发访问的实现。因此，获取和释放应该由一种更具体的资源来强制执行，ConcurrentResource .至少，这对当时的我来说有些道理。

AbstractResource和 AbstractConcurrentResource非常相似，我宁愿避免代码重复，但后者提供与 volatile 相同的实例变量，因为它已经考虑到了并发访问。

我现在正在实现资源管理器，它必须在适用的情况下处理资源获取和释放。意思是，如果资源不是并发的，管理器不必担心它，否则它必须知道它。

这直接转换为 ResourceManager和一个 ConcurrentResourceManager , 因为前者保留一个 Map<String, Resource>而后者需要 Map<String, ConcurrentResource> , 或者很多 Actor 。

拥有两个管理器，意味着其他需要资源管理器的类也必须知道这两个不同的管理器，从而 fork 更多的实现。

我想我可以删除 ConcurrentResource并让这些方法上升到 Resource ，但我真的不确定这种方法。资源本身是否应该在其接口(interface)中提供并发访问的可能性，即使它的某些实现不支持并发？
我认为这可能会产生误导。

---

您将如何处理这种情况？

Answer 1

将关注点分开:不要有一个并发的接口(interface)，而是有一个并发的实现。

类实现要么是并发的，要么不是 - 这是一个实现的选择。并发是关于使内部代码线程安全，而不是关于方法的存在。

参见 ConcurrentHashMap作为 JDK 中这种方法的示例。