-
选项(Option)模式是一种新近流行的设计模式,用于配置类,主要流行于于Go语言(golang)。
每个设计模式本质上就是正对一个场景的一个常见小招式。
选项模式也不例外。它解决的主要问题是:
复杂系统的可复用编码配置。
典型的选项模式的形式是
var system=Systm.New(opt1,opt2,opt3...)通过opt1,opt2,opt3来对系统进行初始化。
复杂系统
选项模式正常情况下一定是解决复杂系统的问题的。
甚至可以简单粗暴的认为选项模式是一个改良的构建者(builder)模式,即配置器列表。
不复杂的系统没有使用选项模式的必要。
对于选项模式,最典型的就是和Builder模式一样,用来处理一个封装类,类里封装了大量的函数/接口,可以根据需要去把这些函数进行替换。
默认可用及扩展性
选项模式的优势其实很大一部分体现在可扩展性上。
由于选项模式的选项都是可选的,而且不可能在代码写完后自动扩展。
所以,选项模式中可以认为一定有部分选项没有被配置过。新建的封装类一定在所有选项中可以运行的默认值。
同样,因为有这个默契,大部分采用了选项模式架构的代码一定有很好的兼容行。因为添加的新的功能和实现必须与原有的行为表现一致。
可以认为这是对代码结构的一种架构上的约束。
基于功能/模块配置
选项模式的主要价值,就是体现在可以分块的,可选的进行配置。
因此,从逻辑上来说,每个选项代表了一种功能,或者模块。
具体来说,举个自理,我的go语言http请求库,默认情况下会生成一个标准请求。比如:
var myreq=preset.New(Host("http://www.baidu.com/)如果我这是一个Post请求,需要带一个纯文字body,代码就变成了
var myreq=preset.New(preset.Host("http://www.baidu.com/,preset.POST,preset.StringBody("12345"))而这个请求如果还需要带上一个特定的请求头,那么就是
var mreq=preset.New(preset.Host("http://www.baidu.com/,preset.POST,preset.StringBody("12345"),preset.Header("auth","abc"))从这个例子应该能喊好的看出选项模式的主要用法了。
在构建复杂系统时,按功能和模块来进行配置,同时提供很多预制件,可以直接初始化为需要的功能。
在系统进行升级扩展时,由于保持默认行为的一致性,也会有很好的兼容性。
在Mud机器人中的应用
从选项模式的特点来看
- 系统复杂
- 高扩展性
- 功能化,模块化
也只有移动模块这个复杂系统需要用得上选项模式。
我在newhelljs的移动模块就是使用了选项模式的架构,具体可以看相关的内容。
-
J jarlyyn 从 Hellclient软件 移动了该主题
-
J jarlyyn 被引用 于这个主题