has*_*sen 72 language-agnostic resources plugins extensibility
我需要一些资源来讨论如何将软件设计为可扩展的,即让其他人可以编写添加功能的附加组件/插件.
您有什么推荐的吗？那里有讨论这个主题的书吗？
我更喜欢那些简短而重要的东西; 一点理论和一堆具体的例子.
我不是针对特定语言,我希望能够理解核心思想,以便我可以用任何语言实现它.
出于同样的原因,我宁愿不使用其他人构建的框架(除非框架不是非常高级,即不会隐藏太多),目前我只想教育自己主题和实验以各种方式实现它.此外,框架通常假定用户对该主题的了解.
UPDATE
我不是在询问OOP或者是否允许我的类被继承.我所说的是设计一个将部署在系统上的应用程序,以便在部署之后可以通过第三方附加组件进行扩展.
例如,Notepad ++有一个插件架构,您可以将.dll文件放在plugins文件夹中,并为不存在的应用程序添加功能,例如颜色选择或片段插入,或许多其他内容(广泛的功能).
bug*_*net 24
如果我们正在谈论.NET,请尝试在CodeProject上使用VBScript编写.NET应用程序.那里有很多具体的例子.
以下是实现各种应用程序扩展技术的站点
Von*_*onC 15
OSGI是一个技术框架的一个很好的实际例子,可以让你做你想做的事情.
该理论是在这里.
的(免费!)书是有.
可扩展性和编写插件的能力必须处理服务生命周期
模块的主要功能之一是作为部署单元......我们可以构建或下载并安装这些功能以扩展应用程序的功能.
你会在这里找到一个很好的介绍,关于服务的核心概念(与你的问题有关,它解释了服务的一些问题,可扩展性的关键组件).
提取:
如果没有它们可以构建如此多的应用程序,为什么服务如此重要？嗯,服务是将软件组件相互分离的最着名的方法.
服务最重要的一个方面是它们显着地减少了类加载问题,因为它们使用对象的实例,而不是类名.由提供者而不是消费者创建的实例.降低复杂性是非常令人惊讶的
服务不仅可以最大限度地减少配置,还可以显着减少共享包的数量.
在您的应用程序中实施SOLID原则。
1.单一职责原则：一个类应该只有一个职责（即软件规范中只有一个潜在的变化应该能够影响类的规范
2.开放/封闭原则：软件实体……应该对扩展开放，对修改关闭
3. Liskov 替换原则：程序中的对象应该可以替换为其子类型的实例而不改变该程序的正确性
4. 接口隔离原则：多个客户端专用接口优于一个通用接口
5. 依赖倒置原则： 应依赖抽象。不要依赖结石
Stackoverflow 问题：
| 归档时间： |
|
| 查看次数： |
26079 次 |
| 最近记录： |