BOS设计缘由(三)

本文探讨了BOS的设计理念,旨在通过组件化和配置文件实现软件的高复用性。BOS将主程序提炼为通用进程启动器,组件和初始化数据分离,形成组件化的软件结构。作为软件框架,BOS不涉及领域细节,适用于多数应用,强调动态组件管理和运行期切换。BOS主要包括组件、组件管理器、进程启动器和配置数据,推动设计思维的转变。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

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源码可在下面链接下载:
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值