面向FooProvider/FooManager和Foo对象的Java创造性设计模式

最近，我开发了一个用户友好的库，它将为用户提供一个资源对象。此资源对象将由我的ResourceProvider/ResourceManager/ResourceFactory实例化，ResourceProvider/ResourceManager/ResourceFactory可能根据不同的上下文有不同的实现

此外，ResourceProvider/ResourceManager/ResourceFactory将基于资源名称在应用程序中为资源对象提供缓存

ResourceManager mgr = ResourceManager.getInstance(context);
Resource r = mgr.getResource('myName')

---

我的第一个想法是使用静态工厂方法。我的问题是什么是这个案例的最佳模式。我认为构建器模式有点过分，因为只有一个上下文参数。欢迎任何意见

那么你的问题是关于API设计的

<>你的API设计是常见的，但并不是没有缺点要考虑。在您的方法中，ResourceManager的每个实例都必须扩展ResourceManager类，有哪些缺点：

• 所有实现与ResourceManager的紧密耦合
• 如果ResourceManager还扩展了其他类（不在您的控制之下），那么这很难
• 违反，因为实现不需要getInstance方法，而是通过ResourceManager提供

从体系结构的角度来看，使用ResourceManager作为接口和额外的提供者来获取实现的设计会更好：

ResourceManager mgr = ResourceManagerProvider.getInstance(context);

但是，还有一个问题：

• 。由于静态的“getInstance”方法，很难模拟ResourceManagerProvider（例如用于测试用例）

最干净的方法是不使用外部静态方法：

ResourceManager mgr = new ResourceManagerProvider().getInstance(context);

（在内部，ResourceManagerProvider可以使用私有静态方法来获得相同的结果。）

但从用户的角度来看，我认为您的方法更受欢迎，因为它易于使用。因此，没有模式或“金子弹”，只是一个决定

---

另一种可能是依赖，但这取决于您的需求。首先使用依赖注入要求库的用户使用与您相同的依赖注入框架，如果您可以注入所需的上下文，则必须使用该框架。使用依赖注入，用户不会直接请求ResourceManager，而是让它从框架中注入

为什么这里需要图案？提供公共接口和依赖项反转，以提供适当的实现。缓存是内部的东西，特定于特定的实现，在本例中完全不相关