我需要一些资源来讨论如何设计可扩展的软件,即以便其他人可以编写附加组件/插件来为其添加功能。

你有什么建议吗?有没有讨论这个主题的书?
我更喜欢简短而切题的内容;一些理论和一堆具体例子。

我不针对特定的语言,我希望能够理解核心思想,以便我可以用任何语言实现它。

出于同样的原因,我不喜欢使用其他人构建的框架来执行此操作(除非该框架不是非常高级,即不隐藏 很多),目前我只想在这个主题上进行自我教育并尝试各种方法来实现它。另外,框架通常假设用户了解该主题。

更新

我不是在询问 OOP 或允许继承我的类。我正在谈论设计一个将部署在系统上的应用程序,以便在部署后可以通过第三方附加组件对其进行扩展。

例如,Notepad++ 有一个插件架构,您可以将 .dll 文件放置在插件文件夹中,并且它向应用程序添加了不存在的功能,例如颜色选择、代码片段插入或许多其他功能(广泛的功能)。

其他提示

OSGI 是一个很好的技术框架实用示例,可​​以帮助您完成您想要的事情。

理论就在这里.

(免费!)书就在那里.

必须处理可扩展性和编写插件的能力 服务生命周期

  • 现场添加/删除服务/插件
  • 管理服务之间的依赖关系
  • 管理服务状态(声明、安装、启动、停止……)

OSGI 是做什么用的?

模块的主要功能之一是作为部署单元……我们可以构建或下载并安装它来扩展应用程序的功能。

你会发现一个 这里有很好的介绍, ,关于中心概念 服务 (这与您的问题相关,并解释了有关服务、可扩展性的关键组件的一些问题)。

提炼:

既然可以在没有服务的情况下构建如此多的应用程序,那么为什么服务如此重要呢?嗯,服务是最著名的软件组件相互解耦的方法。

服务最重要的方面之一是它们极大地减少了类加载问题,因为它们使用对象的实例,而不是类名。由提供者而不是消费者创建的实例。复杂度的降低是相当令人惊讶的

服务不仅最大限度地减少了配置,还显着减少了共享包的数量。

您尝试访问两个相互竞争的目标:

  1. 您的软件的组件必须公开的很多自己的,这样他们就可以被重用
  2. 您的软件的组件必须公开很少自己的,所以他们可以重复使用
  3. 说明:为了鼓励代码重用,你应该能够扩展现有的类和调用它们的方法。这是不可能的,当方法被声明为“私有”和类是“最终”(而不能扩展)。因此,要达到这个目标,一切都应该是公开和访问。没有私人数据或方法。

    当你发布你的软件的第二个版本,你会发现很多的版本1的想法是完全错误的。您需要更改很多接口或代码,方法名,删除方法,打破了API。如果你这样做,很多人会敬而远之。因此,为了能够发展你的软件,组件不得公开任何不是绝对必要的 - 在代码重用的成本

    例:我想观察的SWT StyledText光标(脱字符号)的位置。插入符号是不是意味着要延长。如果你这样做,你会发现代码中包含检查,如“是这个类在包org.eclipse.swt”和很多的方法私人和最终和诸如此类的东西。我只好出SWT的复制大约28个班到我的项目,因为一切都被锁定只是为了实现此功能。

    SWT是使用一个很好的框架和地狱延伸。

实施在应用程序 SOLID 原理。

<强> 1。单一职责原则:的:一种类应该只有一个责任(在软件的规范,即只有一个可能的变化应该能够影响类的规范

2.Open/closed原则:软件实体......应该是对扩展开放,对修改关闭

<强> 3。里氏替换原则: 在程序应该是可更换的与它们的亚型的实例,而不改变该程序的正确性对象

<强> 4。界面偏析原理: 许多客户特定的接口比一个通用接口更好

<强> 5。依赖倒置原理: 一个应当在抽象依靠。不依赖于结核

#1的问题:

例单一职责原理

是开/闭原则是一个好主意?

什么是里氏替换原则?

接口隔离Principle-计划到接口

什么是依赖倒置原则和为什么这很重要?

嗯,这取决于语言。

  • 在 C/C++ 中,我非常确定有一个 loadlibrary 函数,它允许您在运行时打开库并调用它的导出函数。这通常是 C/C++ 中的完成方式。
  • 在 .NET 中,有 Reflection,它提供与 loadlibrary 类似(但更广泛)的功能。还有一些基于反射构建的完整库,例如托管扩展框架或 Mono.Addins,它们已经为您完成了大部分繁重的工作。
  • 在Java中,也有反射。还有 JPF(Java 插件框架),它被用在 Eclipse IIRC 等东西中。

根据您使用的语言,我可以推荐一些教程/书籍。我希望这可以帮到你。

的制品书写基于插件的应用清楚地解释了使用非常简单的示例体系结构的各部分的责任;源代码被提供(VB.Net)。我发现它非常有助于理解基本概念。

结帐 “CAB” - 微软的编辑应用程序构建块框架的。我认为他们已经得到了一个“网络版”太...

我刚开始开发智能客户端应用程序。这是我正在考虑两种选择。

使用微软的 System.AddIn 命名空间。看起来非常有前途,但它可能是我们的最终解决方案有一点复杂。

或智能客户端 - 复合UI应用程序块从微软

最近,我看了服用两种成分综合UI应用程序块和System.AddIn命名空间来建立自己的。由于源代码可用于CAB很容易扩展。我认为我们的端到端的解决方案将是一个轻型版本的CAB的,definatly使用统一应用程序块

插件架构正在成为它的可扩展,因此灵活性非常流行。

有关C ++,Apache的httpd服务实际上是基于插件的,但模块的概念来代替。大部分的阿帕奇功能实现模块,诸如高速缓存,重写,负载均衡,甚至线程模型。这是我见过非常模块化的软件。

和Java,Eclipse是肯定基于插件的。 Eclipse中的核心是一个OSGI模块系统,该系统管理束,另一概念插件。包可以提供上,我们可以建立以较少的努力模块的扩展点。在OSGI最复杂的是它的动态特性,这意味着束可以安装或在运行时卸载。没有停止在世界任何症状多!

如果您使用 .Net,我们的研究得出了两种方法:脚本和合成。

脚本编写

您可以通过使用脚本编排类来扩展类的功能。这意味着以动态语言公开用您最喜欢的 .Net 语言编译的内容。

我们发现一些值得探索的选项:

作品

如果您使用 .Net 4 或更高版本启动项目,则必须仔细研究托管可扩展性框架 (MEF)。它允许您以插件方式扩展应用程序的功能。

托管的可扩展性框架(MEF)是.NET的组成层,可提高大型应用程序的灵活性,可维护性和可检验性。MEF可用于第三方插件可扩展性,也可以将松散耦合插件的架构的好处带入常规应用程序。

托管插件框架 也是一本好书。

由于我没有足够的代表处点发表评论,我张贴此作为一个答案。 SharpDevelop的是发展中国家在C#/ VB.NET /嘘应用程序的IDE。它有一个令人印象深刻的建筑,使自己在许多方面进行扩展 - 从右侧新的菜单项为全新的语言发展的支持

它使用一个位XML配置以充当IDE的核心和插件之间执行一个胶合层。它处理定位,加载和插件版本的开箱。部署新的插件是物质的简单复制新的XML配置文件中所要求的组件(DLL)和重新启动应用程序。你可以阅读更多关于这方面的书由原作者(S)“解剖一个CSHARP应用程序” - 基督教霍尔姆,迈克·克鲁格,从的此处。这本书似乎没有可在该网站上,但我发现了一个副本可能仍然是围绕这里

还找到一个相关的问题此处

而不是重新发明轮子,可使用框架中的手。 Eclipse和Netbeans的都支持基于插件的扩展。你必须用Java工作虽然。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top