在python中有一个非常常用的语法糖@，本质上就是装饰器。这种模式可以不改变原文件的情况下动态的扩展一个对象的功能而不用创建子类，避免了类膨胀，是一种比较常用的模式，有个细节需要注意的就是装饰的顺序。

组合模式(Composite Pattern):将对象组合成树形结构表示来“部分-整体”的层次结构，使用户对单个对象和组合对象的使用具有一致性。

看上去有点抽象，其实就是一种树形结构。比如二叉树，每个非叶子节点都有2个子节点，叶子节点除了没有子节点外和父节点、根节点都是一样的。在通俗来说，比如公司的层级架构，从老板(根节点)到经理(非叶子节点)再到员工(叶子节点)，他们有很多共性的东西，比如都有姓名、工号，老板和经理有添加、移除手下员工的能力，而作为员工则只能干活。

从代码实现来说，就是老板、经理、员工使用一个抽象类，而老板和经理实现某些特定的方法，这就是组合模式，十分容易理解。

桥接模式核心原理是将抽象部分和实现部分分析，使二者可以独立的变化。再具体一点，当某个类型由于自身逻辑可以有两个或多个维度的变化，使用桥接模式可以令这些维度变化时不影响其他维度。再举个例子，手机——可以按照品牌来分类，比如苹果华为三星，也可以按照功能分类，比如拍照手机，游戏手机等等。

桥接模式有2个设计原则：

1. 使用聚合而不使用继承。（使用继承一定是在is-a的关系时再考虑使用）
2. 抽象和实现分离。

这篇文章记录nova创建快照时候的过程，根据文档，创建快照其实是向/servers/{server_id}/action发送了一个POST的请求，内容则是类似:

{
    "createImage" : {
        "name" : "image-name",
        "metadata": {}
    }
}

原文，向原作者表示感谢。不过不知道作者是不是在国内学过作文，让我想起了小学时老师教的作文要多引用名人名言哈哈。

几年前当我还是个菜鸟的时候，我过得十分潇洒。

写代码——交给别人review——改代码，绳命是多磨美好！工作内容就是仔细阅读我收到的评论、建议，学着成为一个更优秀的开发者。如今我成长为了一名高级开发人员，给别人做code review成为了我的职责之一，这时我意识到我的经验还不足以完成这种职责转变。

每次给别人做code review时我都感觉到害怕，感觉自己像是一个骗子，很多问题都困扰着我：

我该给这行代码提建议吗？

应该有更好的办法写这段代码，我应该告诉他吗？

他会怎么想？他的经验比我丰富。

改了这一行代码会不会使程序崩溃？

这时我的导师给了我建议。

好的code review聚焦于获得额外的产出，而非仅仅是找到bug。别把review当做是审讯，而当做是一种提高代码质量、发现其他方案、增加学习能力以及加强友谊的办法。

作为reviewer，你对代码的反馈是将渴望贡献的开发者组建成社区的一种主要方法。通过培养一个活跃的社区，你将提升产品、团队、和人生的质量。

这里有一些做好code review的建议。

适配器模式目的就是不改变原有系统的基础上保留其提供的服务，向调用者提供新的接口服务，使得原本由于接口不兼容而不能一起工作的类可以一起工作。（简单说就是增加兼容性，复用已经存在的功能）

笔记本电脑的电源变压器就是这个原理，把交流电转换成直流电。或者把英文翻译成中文，都是适配器模式。

又分为2种：

1. 对象适配器模式
2. 类适配器模式

适配器虽好，但也不要乱用，如果能在设计阶段就统一就是最好的，适配器模式更像是一种补丁。