我想为可以在一个平台下集成各种第三方软件(可执行文件)的软件进行架构设计.
默认情况下,标准项目类型将添加到平台.项目类型定义了执行不同软件的方式及其输入和输出文件.
用户可以自定义可用的标准项目类型,并将其作为定义新自定义执行流的新项目类型添加到平台.
此外,它应该支持轻松扩展和自定义功能.我读到基于插件的架构支持两者.
基于插件的架构有哪些优缺点？我们有更好的架构可以用于这种场景吗？
提前致谢:)
可插拔系统的好处是
可扩展性:可以动态扩展应用程序以包含新功能.
并行开发:由于功能可以作为单独的组件实现,因此可以由不同的团队并行开发.
明确的发展方向:由于插件框架理想地为插件编写者提供了明确定义的界面和文档,因此开发人员有一个清晰的开发路线图.
简单:插件通常只有一个功能,因此开发人员只需要一个焦点
但其中一些优势也是弱点:
可扩展性:插件接口是否预测插件编写器扩展应用程序的方式,或者是否限制扩展.设计可扩展性以满足所有用例通常需要多次迭代,或者非常好的需求分析.
可维护性:插件框架的提供者不仅要确保插件接口满足缩进的用例,清晰且记录良好,而且还可以进化.管理版本和向后兼容现有插件可能非常困难.足够困难,许多实际的实现都不会打扰,并推动插件编写者的责任,以更新每个版本的插件.
复杂性:尽管每个插件在单独测试时都能正常工作,但插件之间的交互可能会导致新问题,只有某些插件组合出现错误.
测试:如果插件系统不提供某种形式的模拟插件运行器进行测试,测试插件可能会很困难,这有时是不可能的,测试只能通过运行真实的插件来实现,这会减慢开发速度.
人工分离:插件通常只有一个焦点,但是插件api提供者设置的单个焦点是什么.如果一个插件编写者发现他需要一个插件可以合理地做两件事(由插件api定义)紧密串联,他可能最终必须实现两个插件并找到提供它们之间的通信的方法,目前不提供api.然后他不得不解决或反对插件框架.
设计一个好的插件环境与设计一个好的库有很多相同的挑战.如果您自己同时生成环境和插件,那么它就不会那么糟糕,因为您可以随着环境的发展更新所有插件,但如果插件api对所有人开放,则需要仔细规划和执行才能获得设计随着环境的发展,避免过多插件重写的权利.
弗雷德布鲁克斯描述的" 第二系统综合症 "提倡所开发的第二个系统通常过于通用,旨在获得最大的灵活性,有时产生"平台内的平台"/" 内部平台效应 ".当需求不存在或未指定时,可插拔设计通常被视为一种出路.为了补偿,软件尽可能灵活,以尝试处理"随之而来的".
如果它描绘了一幅沉闷的画面,那么可插拔 - 可插拔系统可能非常棒且具有很多优势,但它们价格昂贵.在深入了解可插拔系统之前,谨慎地制定满足所需功能所需的所有插件的要求.然后,这将帮助您确定可插拔设计是否值得付出努力,或者一些更简单的方法同样适用.
插件架构的优势显然是灵活性的提高.这允许其他开发人员以首先没有预料到的方式扩展您的应用程序.请注意,有各种插件架构,从灵活到极端灵活.最灵活的一种称为完全插件架构,在eclipse中使用.
缺点是要真正灵活,你必须开发一个结合插件之间的加载,卸载和通信的可靠框架.插件之间的通信也会有轻微的性能开销.
有关如何创建插件架构的讨论,请查看此问题.
京公网安备 11010802040832号 | 京ICP备19059560号-6 