1.4
问题4
和通用软件框架
到目前为止我们已经通过组件技术和一个组件管理器来为例程
1-1
大幅提升了复用性,并且这种复用性还可以在运行期体现出来。遵循这种方式,任何程序的绝大部分代码都可以被剥离为组件,从而使项目呈现出更佳的可复用结构。你也许想立即宣布我们已经发现了软件设计的诀窍—以组件和组件管理器作为基础的通用解决方案。但是,别忘了我们还有问题列表中的第
4
项。这最后一个问题告诉我们,即使我们把
99%
的程序代码都转移到组件中,我们也还必须要在
main
函数中创建一些初始的组件实例,并为它们赋予恰当的属性值,进而正确启动程序。
启动程序所需的这些初始值需要经过微调,因而在实际项目中它们会不时改变。每次改变任何一个初始值,我们都必须重新编译链接包含
main
函数的
Program
类。一次编译链接花费的时间也许不长,但记住重编译终归不是一个好选择。何况也许最终用户也想对启动初始值进行微调—他们可没法完成重编译这样的高难度动作。
解决方法同样并不复杂。基本上这就是一个魔术常量的问题,因此把它们移到一个外部配置文件中即可。通过改变这个配置文件,最终用户和我们都可以轻松的定制程序启动参数。
从某种意义上来说,程序启动时实例化哪些组件也是一种初始化参数。这些信息也可以被写到外部配置数据之中。如此一来,主程序只剩下极少一部分代码,并且是一段公式化的通用性代码。这可以给我们一些设计上的灵感:不妨将主程序提炼为一个通用性设施,而将应用相关的逻辑和数据剥离开来—应用逻辑被剥离到不同的组件,应用启动时初始化数据则转移到配置文件之中。如此一来,我们将获得一种与以往截然不同但具备高度复用性的设计结构。这种结构的最直观表现是:应用完全由组件构成。
这种设计结构正是
BOS
想要传达的东西。它所给于我们的好处就在于:软件从此实现了完全的组件化;主程序和
exe
只是作为通用的进程启动器而存在;初始化数据被完全剥离到独立的配置文件,从而可以单独配置并杜绝魔术常量的错误。闭上眼睛,你可以很清晰的想像一幅积木式的软件结构图—这是一幅充满美感的结构化艺术图。
1.5
小结
本文向你展示一个充斥日常生活的平凡程序如何被提炼为一个具备高度复用性的软件结构。最终的结果正是帖子中讨论的话题—
BOS
。
但本文不是严格的技术讨论。诸如组件标识、配置数据格式这些细节在本章并没有详细讨论。本文的目的在于指明
BOS
的设计意图,让你对欲解决的问题以及如何解决这些问题有一个宏观的认识。更详细的设计之旅则会在稍后的文章中展开(如果需要的话:-)
BOS
的设计意图是建立一个适用于绝大多数应用的通用软件结构。总的来说,
BOS
兼具组件系统和软件框架两种意义。
BOS
完全基于组件技术,它不仅定义了组件格式,还定义了组件的应用环境—一个动态的组件管理器。这个相当于动态版本的
COM
注册表的设施,允许我们在运行期切换组件实现,从而强化了组件的应用范围和能力。
BOS
又是一个软件框架。与其它软件框架不同的是,它不包含任何领域相关的细节,而只是作为一个组件启动器而存在。因此,它可以通用的为绝大多数应用所采纳,而软件应用也因此得以实现完全组件化。
从组成上来观察
BOS
,则可以简单的讲,
BOS
包括组件、组件管理器、进程启动器和配置数据。其中,组件管理器和进程启动器由
BOS
系统开发者提供,而组件和配置数据则由应用开发者提供。
正如你所见,BOS并不是一个复杂的结构,但其应用范围和威力却不容小视。它的实质是一次轻巧而有力的设计思维转型,其结果则有可能是设计领域一次新的革命。
本文为BOS(Basic
Object
System)相关文档。BOS是一个通用软件框架。BOS源码可在下面链接下载: