设计模式

坚持，一定可以读完的。

复用，永远是一种诱惑，与其说是对程序员的诱惑，不如说是对公司管理层的诱惑。复用，暗示着一次投资多次回报。于是，公司投入重金和大批的技术骨干，期望开发一本万利的平台软件。软件工程里面，以变化闻名于世的，是需求。商业平台软件的项目经理们，基本无力抵抗客户和盈利的重重压力。于是乎，源源不断的各式各样新需求加入进来了，各种奇奇怪怪的bug也被创造出来了，没完没了的bug fix，让技术精英们疲于奔命，勉力维持眼前的苟且，诗和远方的浪漫情怀与雄心壮志，早已消失殆尽。于是乎，平台软件迅速变得臃肿不堪，quanlity迅速退化，迎接它们的，只能是被嫌弃和被抛弃的命运。

Linux的开发，是另外一个故事。Linus不属于任何商业机构，不需要考虑商业回报，不会有项目进度压力，不会因为技术以外的因素来影响技术决策，所以，Linux的quality才能保持下去。如果换成一个商业机构来主持Linux开发，很难想象Linux是否还能如此成功。

什么是程序员的复用？

White-box Reuse Vs. Black-box Reuse White-box reuse: implementation inheritance.

Black-box reuse: interface inheritance + composition

Favor object composition over class inheritance

——————————————————

三种复用类型：

1. Class inheritance: include implementation inheritance and interface inheritance, R.g., Template Method

2. Object composition: Strategy

3. Parameterized Types: C++ template

———————————————————

Design reuse vs. code reuse

Code reuse: infrastructure layer

Design reuse: domain layer, application layer and interface layer

———————————————————

Smart Reuse Vs. Lazy Reuse

Smart Reuse: 领域层复用，抽象来实现服用。广泛的分析业务领域的各个场景，各个交互对象，提炼出反映业务本质的共性。当有特殊情况需要处理时，说明抽象出了问题。

Lazy Reuse：简单的贴标签。具体实现的复用。没有核心本质的共性，仅仅只是表面上相似。

细节是容易变化的，对细节的依赖会使设计失去弹性，任何一个corner case没考虑到，就会对依赖于它的众多对象们产生不可预知的影响，而最终，这种影响会扩散成系统级灾难。

肉丸的故事

你和你的好基友，知根知底，你甚至知道好基友明天会带8个肉丸到公司当午餐，你也知道你的好基友其实只能吃下6个肉丸，而你，也喜欢吃肉丸，午餐也要吃6个肉丸，由于你知道你的好基友会多出2个肉丸，于是，你决定只带4个肉丸去公司做午餐。不幸的是，你的好基友在上班路上摔了一跤，午餐盒摔烂了，8个肉丸全洒了。谁也不知道自己什么时候会摔跤，这就是个corner case。于是，你的好基友要求你分一半的肉丸给他做午餐，你的午餐变得只剩2个肉丸，注定下午饿肚子。问题是，下午4点你请了假，去参加一场重要的网球比赛，这场比赛对你非常重要，它的结果会决定你能不能从业余组晋升到职业组。考虑到你的年龄，这是你最后的机会。赢了，你就可以变成职业网球运动员，像德约科维奇一样赢取公开赛冠军，拿千万年薪；输了，就只能认命了，在公司搬一辈子砖。由于中午没吃饱，没体力，这场重要的比赛毫无悬念的输了，最终，你不得不在公司搬一辈子砖。回顾整个经历，你会懊悔，为什么不好基友吃好基友的肉丸你自己吃自己的肉丸，不必要的依赖，毁掉了你进军职业网球界的人生梦想。

教训啊！

针对接口编程，不要针对具体实现编程。

当你和你的好基友，需要协作完成一个具体任务时，通过必要的接口进行交互，你不需要关心你的好基友中午是吃肉丸还是排骨，他的肉丸洒了，只会影响他，不会影响到你。

同样的，各对象通过接口互相协作，完成具体事情，对象内部的实现细节，各自负责。这，就是封装的意义。

对象的创建过程，特别是复合对象的创建，无疑是涉及到具体细节。creational patterns(factory method, abstract factory builder, prototype and singleton)，正是为了解决如何有效封装创建对象的这一细节而提出的。

例子：可口可乐流水线给瓶子拧盖子。

流水线的机械臂不需要知道自己拧的是可口可乐，健怡可乐，零度可乐还是雪碧，它只需要提取关于各种饮料瓶的特征参数，如瓶子的高度，瓶盖的直径等对流水线机械臂产生影响的参数，其他诸如饮料品牌、瓶盖颜色等，跟该场景的目标（拧紧盖子）无关，这无需考虑。

1. 提取特征的过程，就是抽象的过程。

2. 这组特征参数，就是接口，机械臂根据这组参数来设置机械臂的坐标、角度和力度，这个过程就是，映射到OO，就是针对接口编程。

3.机械臂不需要知道饮料瓶子对象的品牌，瓶子颜色等无关细节，瓶子对象也不需要知道机械臂的各种参数设定细节，这体现了OO封装的思想。各个对象，例如机械臂和瓶子对象，互相隐藏实现细节，而通过接口互相协作，完成目标。