浅谈设计之源 & 之美

艺术来源于生活，又高于生活。其实软件设计也是一门艺术，看一个好的设计也是一种美的欣赏。每个人都喜欢艺术之美，我想每个程序猿应该也是喜欢美的设计的。

关于艺术还有一句话：生活从来都不缺少美，只是缺少发现美的眼睛。软件设计也是如此，有心去观察、思考，就能发现设计之美，也能从生活中找到设计之源。

面向接口编程

我一直认为，这个理论是一个非常有指导价值的设计理论，在我的架构设计中，也一直坚持这一指引。而这一理论在生活中到处都是。

比如在公司想申请一支笔，公司的指引中会写明找行政人员申请，而不会指定找哪个行政人员。因为具体的行政人员可能更替，但行政人员这一接口是一直存在的。或者一个公司具体的行政人员可能会有多个，而只需要找到其中一个便可处理。

需要强调的是，接口不应该仅仅是interface，也可以是一个类，这个很多程序猿都误解了。这里所谓的接口，其实是指能满足要求的最顶层定义。

比如需要对输出流进行操作，并且只需要写入byte[]，那么在设计时可以使用OutputStream，因为OutputStream已经能够满足我们的需求。但是OutputStream并不是一个interface，而是一个abstract class，但是这仍旧符合面向接口编程的设计思想。

组合优于继承

在一个开发团队中，我们会有产品经理、项目经理、开发人员、UI人员、测试人员等，将这些不同角色的人员组合成一个开发团队，每个成员负责自己专业的那部分工作，使得责任、功能变得很清晰，并且人员是可替换的，使得管理层可以轻松地对多个团队进行进行重新组合，或者成立新团队时可以从旧团队挖角，并快速组合成为另一团队。并且如果项目进行时需要系统架构师的加盟，则可以找一个现成的架构师加入即可，简单快捷。

很难想象，如果一个开发团队只有一个人，虽然这个人可以完全胜任产品经理、项目经理、开发人员、UI人员、测试人员等角色，但这是一个不可分割的整体，无法重新进行编排。并且如果项目需要有系统架构师加盟时，这个人就需要去学习系统架构的知识，这就是一个非常耗时工作了。

所以现在很多项目都建议采用纵向切割的方法，把所有功能模块切割到很细的粒度，每个基本功能单元只完成特定的功能，而一个完整、复杂的业务功能则由这一系列单一的功能组合而成。如此，则如果业务需求发生变化，则只需修正特定几个单一功能，而不需要对全部业务逻辑进行重新修正。或者业务增加新的需求，并且这个需求在其他功能中已存在，则可以直接组合进来，而无需再开发业务细节，可大大提高开发效率。这个也是“不重复发明轮子“的一个应用。

GoF的23个设计模式

设计模式的经典名著——Design Patterns: Elements of Reusable Object-Oriented Software，中译本名为《设计模式——可复用面向对象软件的基础》的四位作者Erich Gamma、Richard Helm、Ralph Johnson，以及John Vlissides，这四人常被称为Gang of Four，即四人组，简称GoF。

很多程序猿在看这些设计模式，当然一开始都觉得艰涩难懂，我也是在翻了N遍之后才突然顿悟的，这估计是唯一一本被我翻破的书了。

其实这些模式都可以从现实生活中拿到大量具体的例子，接下来我会尝试去找这些例子，不过我可能不会把23个设计模式都整理出来，望阅读者谅解。

原型模式

中秋又快到了，月饼也开始占领着商场、超市的主要展柜。做月饼时我们通常会把做好的材料放到一个模具里，压实，然后倒出来，一个月饼也就制作完成了。月饼模具会有各种形状，比如圆形、方形等，也许一些老者家里还会有鱼的形状。使用模具使得我们在做月饼时更快，并且可以更快地作出多个相同形状的月饼。中秋过后，我们会把模具洗干净收起来，明年中秋又可以拿出来用了。

这就是中华民族用了几千年的原型模式。原型模式就是在一开始制定了一系列的对象模具，而在需要创建对象时，从模具中生产一个出来，新生产出来的对象会具有模具所设定的属性，这样可以加快对象的创建及初始化。

适配器模式

如果说家里的插座都是三孔的，或者二孔的已经被占用，只剩下三孔的，而此时又有一个二孔插头的电器需要插电使用，那我们通常会去找一个拥有二孔插口、并且其插头是三孔的排插来提供转换。这个排插就是一个适配器，而这个做法就是一个适配器模式的应用。

适配器模式就是对两个不兼容的接口进行转化，使之兼容，适配器只对数据格式进行转化，并不完成具体的业务逻辑处理。

生活启示录

接下来，我打算开始尝试去整理一些不在GoF的23个设计模式里的模式。

手机与插头

最近有几位同事问了我一个相似的问题：有这么一个项目，有90%的功能是公用的，而另外10%会需要根据不同的用户进行定制，目前的做法是使用版本分支来管理，就是有一个新的用户定制功能就增加一个分支；但是这样代码管理上会非常麻烦，特别是当公用功能发生变化之时。

这个需求在生活中已有很完美的实现。比如手机的生产，现在每个手机生产厂家都会将手机卖往世界各地，对于手机这个核心部件来说，不同地区是一样的，就是手机卖往美国和卖往中国是一样的，但是因为不同地区充电插座的规范并不一致，所以会在打包时根据不同地区搭载不同充电插头。

回到之前那个设计，我们可以将公共功能做成一个公共组件，而不同用户的需求做到各自的组件中，打包发布时根据不同的用户打包公共组件+自定义组件。这样做既可以解决自定义组件与公共组件的依赖，也可以使代码的管理更轻便。还可以在合适的时候将不同用户的自定义组件再抽取出相似功能，提取出适合部分用户的公共组件。就像早先充电器归充电器，数据线归数据线，而现在变成数据线和充电线是同一条，而插头变成一个插座和USB的适配器了。相当于数据线也是公共组件，而只有插头才是每个地区定制的了。

小结

所有的设计模式都可以从现实生活中找到例子，还在为设计模式艰涩难懂的程序猿可以先放下书本，静静思索生活中的实例，必有收获；同时我们也可以从生活中提取一些新的设计模式，应用于项目的架构设计，必能增色不少。

生活中有些实例甚至是经过几百、几千年的沉淀演化而来，其思索之深入，非一般可比。