之前，我曾提出软件设计的七个原则，即重用、扩展、变化（后改为协作）、简约、一致、分离、间接，并在去年的亚太软件研发团队管理峰会阐释过自己的想法。经过这两年的积累，这些内容逐渐丰富起来，而我也根据自己所思所想做了一些调整。我的朋友姜大胡子和刘冰对我提出的这几个原则，表示兴趣和部分认同，但同时也提出一些自己的看法。按照大胡子的意见，一个人的记忆很难记住太多的原则，最好不要超过3个。七个原则好似古龙的七种武器，听起来很拉风，其实会让人难以记忆。

通过反思这几个原则，我固然同意大胡子的看法，但让我愿意改进的根本原因，还在于我发现这几个原则其实并不在一个抽象层次上。例如，重用和扩展，其实是我们希望达成的目标，它与间接、分离等原则有着根本的不同。所以，我一直思考着该如何改进这七个原则。之前，我已经初步对这七个原则进行了划分。但我始终比较纠结，例如在“重用”原则中，我总结了一些好的设计理念。譬如说，通过粒度的划分与依赖的解耦，以保证有效的重用。从这些设计理念来看，至少在这个层次上，这几个原则又是平行的。

上次在北京邦元素咖啡的一次技术人士聚会，大胡子给出了他的一套体系。我很认同他在价值观与原则的一些看法。最近，根据自己的一些思考和深入分析，才发现之前提到的“重用”和“扩展”原则中的设计理念，其实仍然可以通过遵循一致、分离与间接原则来保障。渐渐地，这个模型开始成型了。如上图所示，我将这个简单的模型称为设计匠艺模型。

整体来看，模型分为左、右二图。左图的核心圈，描述的是“简单”价值观。这意味着我们在设计时，需要时刻体现设计的简单性。这同时也是UNIX编程艺术中反复提到的原则。将其放在价值观中，是希望突出它的核心地位。从这点来看，我这个模型与大胡子的模型完全相同。

“简单”价值观的外面，是三个主要原则（核心原则）：间接、分离与一致。它们不仅是设计的重要原则，同时也是架构的重要原则，尤其是分离与一致（可以阅读我的这篇博客《软件架构的一致性》），可以通过关注点分离与架构风格一致性，成为软件架构过程中必须遵循的关键原则。这些原则没有包含“抽象”原则，是因为我认为“抽象”其实是“间接”原则的一种体现。“间接”原则的含义更广泛，事实上，它还能够有效地体现对象的封装。正如我的结论，GOF 23种设计模式中，所有模式都体现了“间接”原则。若有不同意见，欢迎PK。

右图是我们在软件设计中必须要达到的目标（或者说是尽可能达到的目标），即软件的可重用性和可扩展性。它事实上可以看做是软件系统的质量属性。在质量属性中还有其他属性，例如安全、性能、可伸缩性、可维护性等，但我认为这些属性更偏向于纯粹的架构过程。而重用与扩展则是架构与设计都需要保证的。

中间的箭头代表设计手段。虽然有很多设计的手段，但我始终认为面向对象设计的最大难点，还是在于职责的识别与分配。这正是我提出“协作”手段的原因。而对于一个好的软件系统而言，和谐的对象协作正是设计的主旋律，也是软件质量的正确保障。图中的三角形表现了“协作”原则的主要内容，包括自治对象、专家模式与场景驱动，中间的一块三角型，则是理想的对象协作模型，即形成好的对象社区。这些内容算是对整个模型的一些补充。

今天打算抛砖引玉，让大家指出模型的不妥之处。这个模型涉及到很多设计的方法、原则，透视了设计的本质，而这些内容则需要大量的篇幅来描述，而这正是我下一本书的主要内容。我会在今后的博客中陆续给出这个设计匠艺模型的细节内容。