软件架构设计感悟

摘要: 维护了一个牛人的模块，其中的一点领悟。

如果你要开一家能处理公司相关业务的公司。你将要面对如何设计这个公司的职能部门，定义工作岗位，业务如何通过这些职能部门进行处理的问题。如果是10人以内小公司，那无所谓。如果是上百人的公司，那么就得有详细的职能部门划分，有规范的业务办理流程。
软件的架构设计与设置一家公司的组织架构有异曲同工之处。

接口类，其实就是定义一个工作岗位。定义了这个岗位的职能范围。
每个类实例化的对象，其实都是这个工作岗位上的员工。

设置一个工作岗位之前，我们一定要想清楚这个岗位的职能范围。要给这个岗位命一个明确（一看就知道它的职能）的岗位名称。
这个岗位上的员工只能从事岗位职能范围内的工作。我们不能随意给这个岗位添加与这个岗位预想职能范围不符的职责。比如：“项目经理”，不能因为开发需发把编码的工作强加给它。职能范围要划清，什么该做，什么不该做，一定要明了。（单一法则）

社会很多关系都是上下级关系的。一个工作岗位上可能手下会有几个别的岗位。如：项目经理下可能会有软件组长、硬件组长、平台组长。而这些组长下，还会有其它岗位。（组合模式）

下属辞职必须要与上级解除上下级关系（人都走了，我怎么让他工作）。上级也可以为岗位招聘新员工（new成员变量）。如果上级被解职，那么其有义务辞掉（delete）其下属（不能不干事儿领空饷）。

上级可以向下级下达工作指令（直接调用）。下级属需要上级协助，那么可以向上汇报（发信号）。如果直属上级不能处理，可以接着向上汇报，直到被上级处理。（职责链）

一个良好的架构，有很明朗的业务流程规则。当我们在增添一个新的业务流程的时候，我们希望一眼就能找到最直接最正确的工作流程。而不是：“这样可以实现，那样也可以”。否则会让我们浪费大量的时间来犹豫，且最终不一定能选择到正确的实现方法。维护的人多了，各创一套，杂乱无章。

一个应用中，顶多只能有一个单例（应用实例本身）。所有的对象都应该在编制内。

想到的就这么多，欢迎指正。