每个设计模式本质上就是正对一个场景的一个常见小招式。

选项模式也不例外。它解决的主要问题是：

复杂系统的可复用编码配置。

典型的选项模式的形式是

 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的移动模块就是使用了选项模式的架构，具体可以看相关的内容。