当前位置:  开发笔记 > 编程语言 > 正文

策略或适配器模式?

如何解决《策略或适配器模式?》经验,为你挑选了1个好方法。

我想创建每个虚拟服务器提供程序的一些类,例如:

数字海洋

的Linode

亚马逊AWS

每个Provider都有自己的PHP类(通过composer)来使用他们的API接口,我想使用他们的类库,但我想确保我可以为每个提供者使用相同的方法.例如关闭VPS:

Linode API方法: powerOff()

数字海洋API方法: haltServer()

而不是使用powerOff()haltServer()- 我想为shutdown()我将创建的任何提供程序类使用方法.我应该使用策略设计还是适配器模式?



1> CKing..:

我应该使用策略设计还是适配器模式?

这是每个人在设计应用程序(包括我自己)时所犯的经典错误.理想情况下,您应该浏览可用设计模式列表并选择最符合您问题的模式.相反,您应该提出初始类设计,然后尝试确定最能描述您设计的模式.这可以保护您免于过度设计,即创建您不需要的不必要的组件.随着时间的推移,您很快就会拥有实际使用的设计模式词汇,而不是尝试使用特定设计模式的应用程序.

抛开设计模式,看起来你正在寻找的是一种提供使用不同底层库/方法执行相同功能的通用接口的方法.这听起来很像抽象授权.

你可以实现的抽象定义称为通用接口提供规范操作方法,如shutdown,connect,retry,等你可以创建一个具体提供者类为每种类型的供应商,如AWSProviderLinodeProvider贯彻shutdown,connectretry方法.然后,通过在这些方法中调用提供程序特定的API来使用Delegation.例如,调用powerOff内部方法shutdown的方法LinodeProvider类.

如果你现在好好看看你的设计,你会开始意识到它看起来像战略以及Aadpter模式.这两种模式的区别在于抽象发挥作用的时间点.如果您决定在应用程序的运行时通过Factory使用的Provider实现,那么您正在使用策略模式; 但是,如果在编译时做出此决定,则表明您正在使用适配器模式.除了模式的名称,你的类看起来几乎一样.

这种方法的优点是您不仅可以识别正确的模式,还可以通过使用Command模式等模式来保护自己免于过度设计应用程序.


阿门.虽然人们应该意识到模式,但它们不应该像设计形成时那样推动设计决策.
推荐阅读
ar_wen2402851455
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有