我需要一些资源来讨论如何将软件设计为可扩展的，即以便其他人可以编写添加功能的附加组件/插件。
你推荐什么？那里有讨论这个主题的书吗？ 我更喜欢那些简短而重要的东西;一点理论和一堆具体的例子。
我不是针对特定语言，我希望能够理解核心思想，以便我可以用任何语言实现它。
出于同样的原因，我宁愿不使用其他人构建的框架（除非框架不是非常高级，即不会隐藏太多），那一刻我只想在这个问题上进行自我教育，并尝试各种方法来实现它。此外，框架通常假定用户对该主题有所了解。
更新
我不是在询问OOP或者是否允许我的类被继承。我正在谈论设计一个将部署在系统上的应用程序，以便在部署后可以通过第三方附加组件进行扩展。
例如，Notepad ++有一个插件架构，您可以将.dll文件放在plugins文件夹中，并为不存在的应用程序添加功能，例如颜色选择或代码段插入，或者许多其他事情（广泛的功能）。
答案 0 :(得分：24)
如果我们正在谈论.NET，请在CodeProject上尝试Scripting .NET applications with VBScript。那里有很多具体的例子。
以下是实施各种应用程序扩展技术的网站
答案 1 :(得分：14)
OSGI是一个技术框架的一个很好的实际例子，可以让你做你想做的事。
可扩展性和编写插件的能力必须处理服务生命周期
模块的一个主要功能是作为部署单元......我们可以构建或下载并安装这些功能以扩展我们应用程序的功能。
您会在 服务 的中心概念上找到good introduction here（与您的问题相关，并解释有关服务的一些问题，关键可扩展性的组件。）
提取物：
如果没有它们可以构建如此多的应用程序，为什么服务如此重要？嗯，服务是将软件组件相互分离的最着名的方法。
服务最重要的一个方面是它们可以显着减少类加载问题，因为它们可以处理对象实例，而不是类名。由提供者而不是消费者创建的实例。降低复杂性是非常令人惊讶的
服务不仅可以最大限度地减少配置，还可以显着减少共享包的数量。
答案 2 :(得分：4)
您尝试达到两个相互竞争的目标：
说明：为了鼓励代码重用，您应该能够扩展现有的类并调用它们的方法。当方法被声明为“私有”且类是“最终”（并且不能扩展）时，这是不可能的。因此，要实现这一目标，一切都应该是公开的和可访问的。没有私人数据或方法。
当您发布软件的第二个版本时，您会发现版本1的许多想法都是完全错误的。您需要更改许多接口或代码，方法名称，删除方法，打破API。如果你这样做，很多人会拒绝。因此，为了能够发展您的软件，组件不得暴露任何非绝对必要的东西 - 代价是代码重用。
示例：我想在SWT StyledText中观察光标（插入符号）的位置。插入符不是要扩展的。如果你这样做，你会发现代码包含像“org.eclipse.swt包中的这个类”这样的检查，并且很多方法都是私有的，最终的和诸如此类的东西。
我必须将SWT中的大约28个课程复制到我的项目中才能实现此功能。SWT是一个很好用的框架，可以延伸。
答案 3 :(得分：4)
在您的应用中实施SOLID原则。
<强> 1。单一责任原则： 一个班级应该只有一个责任（即软件规范中只有一个潜在的变化应该能够影响班级的规范
2.Open/closed原则： 软件实体......应打开以进行扩展，但已关闭以进行修改
<强> 3。 Liskov替换原则： 程序中的对象应该可以替换为其子类型的实例，而不会改变该程序的正确性
<强> 4。接口隔离原则： 许多客户端特定接口优于一个通用接口
<强> 5。依赖倒置原则： 一个应该依赖于抽象。不要依赖于结核
Stackoverflow问题：
Example of Single Responsibility Principle
Is the Open/Closed Principle a good idea?
What is the Liskov Substitution Principle?
Interface Segregation Principle- Program to an interface
What is the Dependency Inversion Principle and why is it important?
答案 4 :(得分：3)
当然有着名的开放封闭原则 - http://en.wikipedia.org/wiki/Open/closed_principle
答案 5 :(得分：2)
这取决于语言。
根据您使用的语言，我可以推荐一些教程/书籍。我希望这很有帮助。
答案 6 :(得分：1)
文章Writing Plugin-Based Applications使用一个非常简单的例子清楚地解释了架构各个部分的职责;提供源代码（VB.Net）。我发现它对理解基本概念很有帮助。
答案 7 :(得分：0)
Checkout“CAB” - Microsoft的组合应用程序构建块。我认为他们也有“网络版”......
答案 8 :(得分：0)
我刚刚开始开发智能客户端应用程序。这是我正在考虑的两个选项。
使用Microsoft的System.AddIn命名空间。看起来很有希望，但对我们的最终解决方案来说可能有点复杂。
智能客户端 - 来自Microsoft的Composite UI Application Block
最近，我已经研究了使用Composite UI Application Block和System.AddIn命名空间构建我自己的组件。由于源代码可用于CAB，因此很容易扩展。我认为我们的最终解决方案将是CAB的轻量级版本，绝对使用Unity Application Block
答案 9 :(得分：0)
插件架构因其可扩展性和灵活性而变得非常流行。
对于c ++，Apache httpd服务器实际上是基于插件的，但是使用了模块的概念。大多数apache功能都是作为模块实现的，如缓存，重写，负载均衡甚至线程模型。这是我见过的非常模块化的软件。
对于java，Eclipse绝对是基于插件的。 Eclipse的核心是一个OSGI模块系统，它管理bundle，这是插件的另一个概念。 Bundle可以提供扩展点，我们可以用更少的努力构建模块。 OSGI中最复杂的是它的动态特性，这意味着可以在运行时安装或卸载软件包。再也没有停止世界综合症了！
答案 10 :(得分：0)
如果您使用.Net，我们的研究产生了两种方法：脚本和组合。
<强>脚本
通过使用脚本编排它们，可以扩展类的功能。这意味着用动态语言公开你最喜欢的.Net语言编译的内容。
我们发现值得探索的一些选项：
<强>组合物
如果您使用.Net 4或更高版本启动项目，则必须仔细查看托管扩展性框架（MEF）。它允许您以插件方式扩展应用程序的功能。
托管扩展性框架（MEF）是一个组合层 .NET提高了灵活性，可维护性和可测试性 大型应用。 MEF可用于第三方插件 可扩展性，或者它可以带来松散耦合的好处 类似于插件的架构，适用于常规应用程序。
Managed Add-in Framework也是一本很好的读物。
答案 11 :(得分：0)
由于我没有足够的回复点来发表评论，我将此作为答案发布。 SharpDevelop是一个用于在C＃/ VB.NET / Boo中开发应用程序的IDE。它有一个非常令人印象深刻的架构，允许自己以多种方式进行扩展 - 从新菜单项到开发支持全新语言。
它使用一些XML配置作为IDE核心和插件实现之间的粘合层。它可以处理插件的定位，加载和版本控制。部署新插件只需复制新的xml配置文件和所需的程序集（DLL）并重新启动应用程序即可。您可以在原作者的书“解剖csharp应用程序”一书中阅读更多相关信息 - 来自here的应用程序的Christian Holm，MikeKrüger，Bernhard Spuida。这本书似乎没有在该网站上提供，但我找到的副本可能仍然在here
还找到了相关问题here
答案 12 :(得分：-8)
不是重新发明轮子，而是使用手中的框架。 Eclipse和Netbeans都支持基于插件的扩展。你必须在Java工作。