Java中的类层次结构 - 与更简单的实现相比更有意义

Question

我有以下类/接口层次结构：

+ 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>或大量演员。

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

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

---

您将如何处理这种情况？

Answer 1

将问题分开：没有并发的接口，而是有一个并发的实现。

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

请参阅ConcurrentHashMap作为JDK中此方法的示例。