设计模式结构型和行为型的感悟-续

es6中有个 Promise 对象。只要接触过的都知道他是一个行为行的模式，我认为他是责任链。

但是我现在想说一个观点，抛开Promise的场景，注意力放在他的结构上。并且稍微变换下Promise对象。假设如下：

let p = Promise.resolve()
p.then(x=>x).then(x=>x)
# 开始变换
p.then(x=>p).then(x=>p)

这样就永远返回p对象了。
接着继续变换

p.then(x=>{
	p.手 = 机械手
	return p
}).then(x=>{
	p.脚 = 木头脚
	return p
}).then(np=>{
	p.身体 = 钢铁身体
	return p
})

这样我就得到一个带有 机械手，木头脚，钢铁身体 的 Promise
上面的代码很蹩脚，再改下

p.then(x=>{
	return 机械手Promise(p)
}).then(机械手=>{
	return 木头脚Promise(机械手)
}).then(木头脚=>{
	return 钢铁身体Promise(木头脚)
})

这样是不是很像装饰器模式了
再来

p.装饰(x=>{
	return 机械手Promise(p)
}).装饰(机械手=>{
	return 木头脚Promise(机械手)
}).装饰(木头脚=>{
	return 钢铁身体Promise(木头脚)
})
# 变换
p.装饰(机械手Promise).装饰(木头脚Promise).装饰(钢铁身体Promise)

这样一顿操作下来，不能从结构形模式来看待Promise吗？？

总结：

1. 我们的语言，一个词语，可以表示动词，也可以表示名词；
2. 抛开场景，句子；来确定我们也无法区分这个词语动词还是名词
3. 这个词语，对应编程的概念就是抽象。比如行为的抽象，类的抽象
4. 代码的命名每个人都不一样。
5. 真正编码的时候，我们往往不可能把某个功能写的如此纯粹。往往能看到很多设计模式的影子。比如：封装外观模式的时候，往往某些功能又用到适配器模式

我想这也是我们学习设计模式最容易走入的误区。

最后，归纳下三种模式

创建型：使用函数或者方法，返回一个对象。不管内部如何，都应属于创建型
结构型：前提要有个骨架，所有属性或者组件都依附在这个骨架上
行为型：具体某个方法或者行为

---

用编程的话说：

# 创建
o = new Object
# 结构
o.a = 1
o.b = 2
# 行为
o.sum(){return o.a + o.b}