我不知道设计模式中是否有这些设计的描述,是否有个正式的名字(底子不好啊)。所以我只能暂且叫“被动扫描”和“主动处理”。下面以一个可扩展菜单的设计为例子。
现在有一个需求,我们希望软件在启动时,根据模块的多少动态的增加菜单,而不是将所有的菜单项用编码写死。
第一种方案是使用XML或者数据库,将所有的菜单记录下来,软件在启动时,读取信息并构建菜单。
第二种方案是主模块公开菜单服务(控件),每个模块启动时主动的调用菜单服务,添加自己的菜单。
俩种方案各有好处,第一种方案使用方便,而且可以在发布给客户时添加新菜单,但缺乏灵活性,例如有个模块竟然需要向菜单中添加一个日历控件,我们就不得不修改原先的扫描程序,来适应新的需求,而且我们预知到新的需求马上就要涌来。
而第二种方案更加灵活,由于是程序操作,将变的非常灵活,你可以来个循环,或者根据权限或者许可证来决定是否加入某个菜单。但这个方式需要大量的代码,给程序的快速开发带来麻烦。
所以就有了第三个方案,合二为一,建立菜单服务,每个模块主动调用菜单服务添加菜单,但是就每个模块添加菜单的部分统一建立一个基类,这个基类就是从XML读取菜单信息,当然,如果XML无法适应你的需求,你也可以自己写代码加入自己的特色菜单。
以上说的设计,实际上有很多软件都是一个例子,例如脚本的概念就是主动处理的插件方式。资源文件就是被动扫描的方式。
现在有一个需求,我们希望软件在启动时,根据模块的多少动态的增加菜单,而不是将所有的菜单项用编码写死。
第一种方案是使用XML或者数据库,将所有的菜单记录下来,软件在启动时,读取信息并构建菜单。
第二种方案是主模块公开菜单服务(控件),每个模块启动时主动的调用菜单服务,添加自己的菜单。
俩种方案各有好处,第一种方案使用方便,而且可以在发布给客户时添加新菜单,但缺乏灵活性,例如有个模块竟然需要向菜单中添加一个日历控件,我们就不得不修改原先的扫描程序,来适应新的需求,而且我们预知到新的需求马上就要涌来。
而第二种方案更加灵活,由于是程序操作,将变的非常灵活,你可以来个循环,或者根据权限或者许可证来决定是否加入某个菜单。但这个方式需要大量的代码,给程序的快速开发带来麻烦。
所以就有了第三个方案,合二为一,建立菜单服务,每个模块主动调用菜单服务添加菜单,但是就每个模块添加菜单的部分统一建立一个基类,这个基类就是从XML读取菜单信息,当然,如果XML无法适应你的需求,你也可以自己写代码加入自己的特色菜单。
以上说的设计,实际上有很多软件都是一个例子,例如脚本的概念就是主动处理的插件方式。资源文件就是被动扫描的方式。