我将与多个提供商集成,每个提供商都有不同的界面,因此我有 2 个选项,并且想选择其中之一:
1-使用适配器,因此我的应用程序内部将具有包含我期望的带有参数的所有方法的接口(interface),并且当获取提供程序 API 时,将通过从我的应用程序实现接口(interface)来为该 API 制作适配器。
2-使用通用代理代理实现特定接口(interface)“可能是适配器选项中指定的接口(interface)”,并且此代理必须调用提供程序 API 并提供我的应用程序使用它的方法
注意 1:您可能认为 2 个选项是相同的,但事实并非如此,在适配器中,您期望提供者 api 具有相同的方法,但名称和参数相同,但可能需要进行强制转换,在代理中,您可以从提供者方面获得更大的灵活性,因此提供者可以是 java api、REST 服务或其他任何东西。
注2:选项1中我和provider api之间的契约是业务共识,但选项2中是必须实现的代码接口(interface)
注 3:我可以在一个解决方案中同时拥有这两种解决方案,在我的应用程序中使用代理并使用适配器来调用提供商 API,如果提供商 API 与我们的业务共识不匹配,则会在其上创建另一个代理,如下所示:
Provider => proxy => adaptor => proxy
但是我是否需要它而不是仅使用代理来包装所有这些?
最佳答案
我认为代理模式并不是为了使预期的接口(interface)适应另一个接口(interface)。也就是说,代理模式旨在解决与以下相关的问题:
- 访问远程接口(interface)
- 访问成本高昂/复杂的界面
这两种情况,代理接口(interface)访问都很方便。
另一方面,您有适配器模式,旨在使真实接口(interface)适应预期接口(interface)。它并不介意您需要的转换是简单还是复杂(如您在注释 1 中所述)。
所以,如果我没有误解你的问题,我认为你更适合适配器模式。
关于java - 使用适配器与代理与多个提供商集成,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/32652527/