关于通用软件框架

术语框架在软件工程中被定义为从相同类型的应用中挖掘出的可复用的体系结构。问题是，相同类型的应用这一限定范围在面对现实世界时往往表现出超出原定预期的多样性。虽然仍然可称作相同类型，但新的应用很容易便在不经意间提出某种超越已有框架能力的需求。一旦出现这种情况，用户通常便踏入了修改扩展旧有框架的泥潭。他们很快发现，即使拥有原框架的源代码，新功能也很难被融洽的添入到框架中。旧有的结构很容易就被修改得面目全非，最终导致整个框架的推倒重来。

 

如果你曾经经历这样的窘境，那么你的第一反应很可能是抱怨框架设计者在通用性上的考虑欠周。然而，既然框架被定义为相同类型应用的归纳，那么它就不可避免地包含有领域相关的细节。一旦你的需求超越了这些细节所定义的结构，这个框架自然有可能在你的压力下出现雪崩。

 

除非，这个框架包含的层面足够广阔，即使在特定的应用层不符合你的要求时，其更低层次的结构仍能使你获得使用上的便利。这样一个理想化的大框架形如下图：

  

 

分层的框架设计

 

 

图形最底端是最为通用的框架层。这个层次不包含任何领域细节，理论上应适合于所有的应用。稍上一层的框架包含有一定的领域相关细节，但这个领域的限定范围足够大，因此该层次仍适用于大部分应用。随着层次向上攀升，领域相关的细节越来越多，相应的层次也就越来越局限于特定的应用范围。最顶层是极其专业化的框架层。也可以认为，最顶层便是某个特定的应用。即使是同一个应用，也存在变化的空间，因此从这个意义上来看，应用和框架并没有明确的界限。

 

遗憾的是，大量的软件框架并非遵循这样的结构完成。通常的情形是，极度专业化的框架的开发者同时也在开发属于通用框架的内容。并且，两者混杂在一起，缺乏明确界定。这样的框架即使由最优秀的程序员来完成，也必然徒劳无功。

 

在确定了软件框架层次观之后，你也许立刻就对最底端的通用框架产生了兴趣。毫无疑问，开发一个理论上能适用于所有应用的软件框架对任何一个编程者来说都具有莫大的吸引力。简单设想一下，这样一个软件框架的开发必定具有极大的挑战性。

 

不过，如果从另一个角度来考虑，通用软件框架的开发未必是件太难的事。因为，既然这个层次不具备任何领域相关的细节，那么它必然极其的简洁。我们所要做的只是抓住它背后潜在的规律，然后一切便如顺水推舟般容易。这就好像是爱因斯坦的那个了不起的公式E=mc ²所揭示出的：上帝喜欢简洁。

具体如何开发，请参考BOS。BOS的源码下载地址： http://sourceforge.net/projects/bos-code