Here's a small video that at least will give you some hints; the Lego Process [less than 2 minutes long]
There's also a complete recipe for how to create your own framework based extensively on Modularization...
The most important key element to make modularized software is to remember that it's purely [mostly] a matter of how loosely coupled you can create your systems. The more loosely coupled, the easier it is to modularize...
function renderBackground() {
foreach (Plugin p in getRegisteredPlugins()) {
if (p.rendersBackground) p.renderBackground();
}
//Standard background code if nothing got executed (or it still runs,
//according to needs)
}
使用插件可以实现的“renderBackground”挂钩来更改背景。
以 API 方式，用户应用程序将调用您的服务来渲染背景。
//other code
Background b = Salesforce2.AjaxRequest('getBackground',RGB(255,10,0));
//the app now has the result of calling you
There are two ways to go around here, which one to take depends on how will your software behave.
One way is the pluginroute, where people can install new code into the application modifying the relevant aspects. This route demands your application is installable and not only offered as a service (or else that you install and review code sent in by third parties, a nightmare).
The other way is to offer an API, which can be called by the relevant parties and make the application transfer control to code located elsewhere (a la Facebook apps) or make the application to do as the API commands enable the developer (a la Google Maps).
Even though the mechanisms vary and how to actually implement them differ, you have to, in any case, define
What freedom will I let the users have?
What services will I offer for programmers to customize the application?
and the most important thing:
How to enable this in my code while remaining secure and robust. This is usually done by sandboxing the code, validating inputs and potentially offering limited capabilities to the users.
In this context, hooks are predefined places in the code that call all the registered plugins' hook function, if defined, modifying the standard behavior of the application. For example, if you have a function that renders a background you can have
function renderBackground() {
foreach (Plugin p in getRegisteredPlugins()) {
if (p.rendersBackground) p.renderBackground();
}
//Standard background code if nothing got executed (or it still runs,
//according to needs)
}
In this case you have the 'renderBackground' hook that plugins can implement to change the background.
In an API way, the user application would call your service to get the background rendered
//other code
Background b = Salesforce2.AjaxRequest('getBackground',RGB(255,10,0));
//the app now has the result of calling you
This is all also related to the Hollywood principle, which is a good thing to apply, but sometimes it's just not practical.
来自 插件模式 /amzn/click/com/0321127420" rel="nofollow noreferrer">EAA 的 P 可能就是您所追求的。 为您的服务创建一个公共接口，插件（模块）可以在运行时临时集成到该接口。
The Plugin pattern from P of EAA is probably what you are after. Create a public interface for your service to which plugins (modules) can integrate to ad-hoc at runtime.
例如，一个视图系统可能会要求组件渲染自身（比如在 HTML 中，或者可能会传递一个渲染区域并要求视图直接绘制到其中
广泛使用动态注册表（加载插件时） ，它向适当的注册表注册）
一个用于将事件传递给组件的系统（例如鼠标单击，光标输入等）
一个通知
用户管理
等等！
This is called a component architecture. It's really quite a big area, but some of the key important things here are:
composition of components (container components can contain any other component)
for example a grid should be able to contain other grids, or any other components
programming by interface (components are interacted with through known interfaces)
for example a view system that might ask a component to render itself (say in HTML, or it might be passed a render area and ask the view to draw into it directly
extensive use of dynamic registries (when a plugin is loaded, it registers itself with the appropriate registries)
a system for passing events to components (such as mouse clicks, cursor enter etc)
发布评论
评论（5）
如果您正在托管应用程序，请发布（并测试）RESTful API。
如果您要分发软件，请查看 OSGi。
If you're hosting the application, publish (and dogfood) a RESTful API.
If you're distributing software, look at OSGi.
这是一个小视频，至少会给您一些提示； 乐高流程 [不到 2 分钟]
还有一个完整的秘诀，教您如何创建您的乐高积木。自己的框架广泛基于模块化...
制作模块化软件的最重要的关键要素是要记住，这纯粹[主要]是您可以创建系统的松散耦合程度的问题。 耦合越松散，就越容易模块化......
Here's a small video that at least will give you some hints; the Lego Process [less than 2 minutes long]
There's also a complete recipe for how to create your own framework based extensively on Modularization...
The most important key element to make modularized software is to remember that it's purely [mostly] a matter of how loosely coupled you can create your systems. The more loosely coupled, the easier it is to modularize...
这里有两种方法，采用哪一种取决于您的软件的行为方式。
一种方法是使用插件路线，人们可以在其中安装新代码到应用程序中修改相关方面。 此路线要求您的应用程序是可安装的，而不仅仅是作为服务提供（否则您安装并检查第三方发送的代码，将是一场噩梦）。
另一种方法是提供 API，它可以由相关方调用，并使应用程序将控制权转移到位于其他地方的代码（如 Facebook 应用程序），或使应用程序按照 API 命令启用开发人员的方式执行操作（如 Google 地图）。
尽管机制有所不同，实际实现方式也有所不同，但无论如何，您都必须定义
最重要的是：
在这种情况下，挂钩是代码中的预定义位置，用于调用所有已注册插件的挂钩函数（如果定义），从而修改应用程序的标准行为。 例如，如果您有一个渲染背景的函数，则可以
使用插件可以实现的“renderBackground”挂钩来更改背景。
以 API 方式，用户应用程序将调用您的服务来渲染背景。
这也与 好莱坞原则，这是一个很好的应用，但有时并不实用。
There are two ways to go around here, which one to take depends on how will your software behave.
One way is the plugin route, where people can install new code into the application modifying the relevant aspects. This route demands your application is installable and not only offered as a service (or else that you install and review code sent in by third parties, a nightmare).
The other way is to offer an API, which can be called by the relevant parties and make the application transfer control to code located elsewhere (a la Facebook apps) or make the application to do as the API commands enable the developer (a la Google Maps).
Even though the mechanisms vary and how to actually implement them differ, you have to, in any case, define
and the most important thing:
In this context, hooks are predefined places in the code that call all the registered plugins' hook function, if defined, modifying the standard behavior of the application. For example, if you have a function that renders a background you can have
In this case you have the 'renderBackground' hook that plugins can implement to change the background.
In an API way, the user application would call your service to get the background rendered
This is all also related to the Hollywood principle, which is a good thing to apply, but sometimes it's just not practical.
来自 插件模式 /amzn/click/com/0321127420" rel="nofollow noreferrer">EAA 的 P 可能就是您所追求的。 为您的服务创建一个公共接口，插件（模块）可以在运行时临时集成到该接口。
The Plugin pattern from P of EAA is probably what you are after. Create a public interface for your service to which plugins (modules) can integrate to ad-hoc at runtime.
这称为组件架构。 这确实是一个相当大的区域，但这里的一些关键重要的事情是：
等等！
This is called a component architecture. It's really quite a big area, but some of the key important things here are:
and much much more!