让架构设计走下神坛

分享下一些架构设计方面的经验:

1. 什么是架构?

盖一个小楼，其架构简单的说是计算梁和柱子的长度，面积，体积，力度，最大荷载和数量等，那么程序的架构是不是也可以理解成接口，类，各种数据类型，算法之间的仓库呢? 以这个概念为引子，下面详细的说明程序的架构是怎么做起来的.

2.设计架构之前，架构师一定是要先了解需求的。

3.从需求分析中，就会设计出第一个蓝图-----该架构该如何分层.

有人会问，我们不都是采用流行的3层架构或3层半架构嘛？ 表现层，业务逻辑层，数据层，web service这样的架构是应用于web开发，一些rich client程序和form程序由于业务需求不同，完全不需要什么表现层或是web service. 有些架构的分层中还涉及到对产品抽象层，启动层，甚至我觉得可以为做代理做一层，为monitor(监视)做一层。总之，没有绝对的框架，都是随着需求的深入而不断改进的。

4.分层后，各层之间是有依赖顺序的。

避免层之间互相引用过多。多引用一层，就意味着引用层可能会引来不必要在此层实现的职责，替被引用层完成本该由它来做的事。之所以分层，就是为了职责明确，各层做各层的事。所以在添加引用的时候，要小心是否真的需要引用这个命名空间。

5.需求里面肯定有一个需要反复操作的对象，那么架构里面，同样也会有一个抽象的对象来对应。对于这种对象，在架构上一般是要多关照的。我一般会参与这种方式: 定一个接口，然后再定义一个抽象类，抽象类来实现这个接口，然后可以用有抽象层次子类来继承这个抽象类。这样做除了一般的面象对象的好处外，可以很大限度的封装变化并减少代码冗余，很容易扩展。这当然根据需求的要求，对于复杂的对象，可以采用这种方式来封装抽象。

解释下为什么对大限度的封装变化:主要归功于使用了接口，并把接口做为最base的那一层。定义一个对象的行为和属性，目前最胜任的就是接口了；如果用抽象类，那么接下来实现其的子类就只能单继承，这样就受限制了。往往，代码改的对大的地方，通常都牵涉到业务的核心对象，所以把变化封装起来。

解释下为什么减少代码冗余:因为有抽象类来实现这个接口，所以该抽象类的子类和孙子类们可以不用实现接口里的全部方法。

解释下为什么容易扩展:由于又有接口又有抽象类和孙子们，无论是给接口赋予特性还是给接口再添加接口成员，都容易实现，而且还有很多层抽象层次，想在哪层添加什么行为，应用何种设计模式，基本上都能满足。

6.接下来，在设计中，该考虑各种对象的相互关系和方法的参数，返回类型的定义。

如果这些都能 定义好，那么在修改设计时就能轻松愉快了；如果不那么理想，就需要这些方法能够重载。

7.选择合适的数据类型是衡量一个架构的标准之一。一般这些数据类型就够用:List<T>, array[], Queue, Stack, 键值对. 再复杂点，就是这些数据类型组织在一起，比如把String, Queue, class的实例放到数组或键值对里。如果对于一些复杂的业务,比如有N层结构的数据,而且有从属关系, 那么用XML来表达更合适。因为这样可以方便准确易懂，而且能适应未来的变化. 这是用Hashtable, List等等不容易做到的。

8.算法。按照程序逻辑的步骤而写的算法也是算法，对程序逻辑抽象后的算法也是算法，当然第二种更好点。对于该怎样写出个好算法有3个好建议, 1是应用面向对象的思想，2是透过现象看本质,3是参考和借鉴别人的，因为毕竟一个人的思想难免会有局限性，所以为什么要有头脑风暴呢。

9.在架构设计里面，容易发生变化的地方是原来用一个变量来表达，后来需求改变，需要用一个数组或队列或其他什么数据结构来表达了，

这样在流程上，影响上就不小，可能会改动很多的代码。 这是我深刻体会到的。原来想象不到 这里居然会改变，所以开始设计的时候就简单的用个变量来表达。

10.最后的一点感受是需要不断的重构，思考，来完善架构。

最后，恳求大家的批评与不同的意见，欢迎拍砖和砸鸡蛋。让我们共同改进提高我们的方法论。

Peace!