[置顶] 欢迎您。今天是2022年11月30日。

软件产品的规模总是越来越大,模块越来越多,如果出现了一点影响到后继开发或者维护的迹象,就要果断的进行重构,将项目及时调整到正常轨道上。开发RCP项目中遇到的典型就是随着插件数量的增多,各个插件之间的依赖性越来越强,这时候如果不进行及时调整,任由其发展下去,等到出现了插件循环依赖,再回过头来整改可就不是那么容易了。很有可能还要影响到相关的业务功能部件。

任何软件系统到了一定的规模后,都可能会产生模块间的无序依赖。造成这种后果的原因可以总结为以下几种:

  1. 封装性不好,随意开放公共类或接口给第三方使用。造成客户代码深度依赖于此模块。
  2. 各个模块各自为政,没有提取公共的接口到基础模块中,使用此模块功能的代码就必须要依赖于此模块。
  3. 没有良好的面向接口编程习惯,直接引用被依赖模块的具体类。
  4. 随意使用singleton模式,只图使用方便,不考虑在设计上是否必要。

对应于Eclipse插件开发,可以理解为:

  1. 在plugin.xml文件的runtime项中,不加限制的开放所有Package的访问权限;或者在开发过程中,没有限制,随需随开,不知不觉中加剧了插件间的依赖程度。而且由于降低的访问的门槛,容易养成编程人员的懒惰思想,不利于提高其设计能力。
  2. 开发初期大多是几个人负责一个模块,各个模块间互不干扰的开发,需要访问其他模块是,典型的做法就是让被使用模块提供一个Singleton的类,然后随心所欲的使用其具体类。负责各模块的人很难在公共基础这一问题上达成共识,或者是根本没有考虑到这一点。没有基础模块的归纳总结,随着业务的增大,很容易就造成插件间的循环依赖。
  3. 使用别的插件的时候,都是直接使用具体类。对插件全部都是依赖于具体类,而不是依赖于抽象。

可供选择的解决方案如下:

  1. 构建良好的接口体系,外部插件对本插件的依赖仅限于抽象。
  2. 提取公共部件到一个基础插件中,其中包括全项目共享的服务和资源。全部插件都依赖于此基础插件。
  3. 插件不依赖于具体提供服务的插件,而是依赖于基础插件,提供服务的插件将服务注册到基础插件中。这样就构建了一个服务注册,获取体系。减轻了各个插件间的依赖程度,降低了服务提供者和服务使用者之间的耦合。此体系可通过扩展点机制实现。
您可能也喜欢

今天给RCP打包测试,遇到了以前的遗留问题,就是打包后配置文件丢失,导致一些功能实现不了,从而用了硬编码实现,今天闲来无事,偶然间把问题解决了。以前用的配置文件格式是ini的,在查看了几个配置文件都是properties格式能打包进去后,我也把ini改成了properties,竟然成功。呵呵~爽啊~

二维码
摄像头