数据在任何产品的开发和设计中, 始终要摆放在首要位置。 跟数据贴近的两个概念是: 数据库, 数据结构. 这两个概念最终都是数据结构。数据库的表结构就是数据结构。 程序 = 数据结构 + 算法 这一经典的公式, 导致我们误读为: 数据结构和算法的地位是等同的. 但实则不然. 对数据结构的态度已经决定你的架构的优劣。 本文想通过J2EE的项目和普通的C/S架构的项目, 来说明一下, 数据结构为中心的思路, 带来的架构上的优雅性。
第一:关于软件产品, 数据结构, 算法的一个简单的比喻
软件产品的核心, 都是对数据进行处理。 举例几个常见的例子: 人力资源管理系统, 最终的目的, 就是将公司的人力资源数据做一些必要的处理, 如增加, 删除, 查找, 涉及到人事变动, 如晋升, 离职, 这些, 都是对人力数据的调整; ERP管理系统, 对公司的进出口数据进行管理; Google公司, 它自己的核心理念, 也是对全球数据进行整合。用户传入查询的数据信息, Google网页将返回查询结果的数据信息.... 等等,这些, 都无外乎数据。 所以说, 软件的核心是数据处理。
数据在其中的重要作用, 可以用日常生活中的:"巧妇难于无米之炊"来形容。 数据就相当于这里的“米”. 我们提到的数据结构, 就是如何存放这些“米”, 可以用不同的容器: 比如锅, 电饭煲, 微波炉等. 存放数据的容器, 就是我们的数据结构。
数据结构的存放方式, 直接影响到数据的处理方式, 同样用“米”来做比方。 假如我们的软件是一个将“生米煮成熟饭”这样一个数据处理系统， 我们有三种方式：
方法序号 数据结构 算法 应用范围和效果
1 普通的铁锅 燃气灶加热 不常用, 不方便控制
2 微波炉 通电加热 基本不用, 耗电大, 时间太长
3 电饭煲 通电加热 常用, 易于控制
这里想传达的意思是, 达到目的"把饭煮熟", 可以用很多方式来实现, 通过组合数据结构和算法, 便可以达到我们的目的.
为了达到更好的目的, 当然我们可以优化算法
, 我们可以这么做:
第一种方法, 用普通铁锅, 我们可以调节火焰的高度, 增加火焰的利用率， 比如用一个圈圈盖在火焰的周围，使得热量集中于铁锅
第二种和第三分钟方法, 我们可以加大电压, 增加电流的方式, 实现快速加热
当然还可以修改数据结构,
第一种方法: 买一口更好的锅, 受热更好的镍铁合金锅, 锅底是凸型的, 更容易受热
第二种和第三种方法: 买更好的电饭煲和微波炉.
如果是你, 你会选择调整盛米的容器, 还是调节加热的方法呢! 如果你不知道, 问问身边的家庭主妇可以得到不错的答案.
(我想我们只会选择电饭煲, 通过通电的方式, 实现“把饭煮熟”这样的目的。 如果要优化, 我们会选择一个更好的电饭煲)
同样, 作为程序员的你, 你觉得在软件设计中, 应该将精力集中在算法, 还是在数据结构上?
(我赞同的答案是花更多的经历设计数据库和数据结构.)
做一个声明, 并不排斥算法设计, 但始终认为有什么样的数据结构, 才会出现什么样的算法. 脱离数据结构去谈算法, 是不可接受的。
第二:经典著述中对数据结构和算法的探讨.
这里将引用《Unix编程艺术》以及《代码大全》中, 关于这部分的理解
第三:数据为中心的架构带来的简单设计
a. J2EE中数据为中心带来的简单性
b. 自己经历的两次软件设计,一次成功, 一次失败。 得出的结论, 数据为中心的结构设计, 让架构更容易理解, 项目更容易维护
-----------------------------一个
UI
和数据纠结的项目
.
项目介绍
:
1.
功能
实现一个计算通信设备功耗的工具
,
通信设备包括基站，
RNC
之类的产品
.
2.
主要的功能
a)
16
种类型以上的设备
,
选择一个或者多个设备类型
,
以此为基础，用户进行配置
.
每种配置包含
20
个左右的参数
.
参数之间存在逻辑关系
,
比如一个参数决定另外一个参数是否出现，出现的值应该是多少
.
b)
可以导入一些实际已经存在的参数文件，根据用户选择的模型，把参数填入到用户配置好的数据中。
c)
UI
显示数据
,
并体现各个参数之间的逻辑关系
d)
UI
更新完毕之后，对配置完好的“数据三”进行计算的操作
,
并在界面上展示结果
.
e)
其它的一些非常
BT
的问题
.
i.
当时该项目是某个主项目的二次开发
,
带来的问题是，主项目存在较多缺陷，提供的接口非常不友好
,
比如
b)
中提及到的
xls
数据源的问题
,
实质上该
xls
是对该主项目的接口
.
但里面存在非常多的无用和冗余数据需要本项目处理
.
ii.
数据中可能存在错误信息，需要本项目去处理
.
这样可能会带来一个严重的问题，数据上的问题，最终将会导致
UI
和计算模块出错
.
iii.
当前项目要考虑主项目任何形式的更改
.
满足维护上的简易性。
前后期版本架构上做了很大的改变
:
1.
前期没有将
XML
结构的数据完全独立成一个类
,
而是直接用
xml
的方式进行解析和数据提供，即使提供了众多的方法
, xml
解析器根本无法代替数据结构，作为一个数据的
API
接口
.
提供对外使用相当困难
.
第二个版本
,
独立出一个
MemoryData,
将树状结构的
xml
梳理成数据结构
,
统一提供对外使用。
2.
各个模块，直接提供文件接口直接解耦和
.
导入
xls
的功能
,
数据立即写入文件
,
当
UI
取数据的时候，不是通过内存获取，而是从数据文件中获取
,
这样，导入功能和
UI
展示功能完全解耦和
(
可能很多人觉得，这样降低了效率
,
但这个牺牲显然是值得的
).
对计算模块更是如此
.
3.
以数据为中心的接口设计
,
当主项目更新的时候
,
当前项目，只需要在源头设计一个过滤器
,
将格式做调整即可，后续的计算模块，
UI
模块，都不受影响，极大的提高了可扩展性。
架构图如下所示
:
可以看出，整个过程，都是以数据为中心的方式进行设计
,
重申一下这个系统的特点
:
1.
所有功能围绕数据进行接口
,
可以想象成为一个过滤器
2.
所有的功能都直接从文件获取接口，以方便彼此间解耦和重用
.