如何使桌面应用程序模块化？

发布于 2024-07-19 10:56:44 字数 37 浏览 5 评论 0原文

如何使 Java 桌面应用程序模块化？模块应该如何分类？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

篱下浅笙歌 2024-07-26 10:56:44

作为设计目标，模块化意味着您希望拥有一个由单独的部分（模块）组成的应用程序，其中每个部分都有其职责范围，并包含与该区域相关的所有类（high 内聚），并且这些部分之间的通信是通过狭窄的、定义良好且记录在案的接口进行的（松散耦合）。

您可以通过提前规划设计并调整这些计划并在实施过程中不断重构代码来实现这一目标。

区分 GUI、网络通信或 DB 访问等技术模块（通常形成层，尽管这些模块可能会细分为多个模块）和包含特定于应用程序的逻辑但通常不包含这些逻辑的域模块是很有用的。形成层。

回复收藏 0 原文

孤凫 2024-07-26 10:56:44

查看 OSGi 技术。应用程序的每个模块（称为捆绑包）都是一个单独的 jar，OSGi 负责依赖项解析和动态加载捆绑包类路径等。

对于桌面应用程序，我强烈建议从 www.dynamicjava.org。它使您的应用程序部署变得更加容易。他们还有一些东西，比如动态 JPA，对任何 OSGi 应用程序都很有用。

回复收藏 0 原文

栖竹 2024-07-26 10:56:44

你是指像 Eclipse 这样的模块化吗？

如果您的 Java 桌面应用程序基于 Eclipse RCP 或 NetBeans RCP，您将“免费”获得模块化（几乎;-)）

回复收藏 0 原文

苏佲洛 2024-07-26 10:56:44

您的问题的答案实际上取决于您所说的“模块化”是什么意思。

在使应用程序模块化时，您必须考虑几个级别的问题。

首先，您必须考虑您寻求的“模块化”是架构模块化、部署时模块化还是运行时模块化。

无论如何，每个连续级别都意味着所有先前级别。

对于初学者来说，要使您的应用程序模块化，您必须从架构开始。将您的关注点分解为明确定义的清晰部分，这些部分具有与“外部世界”明确定义的接口。使用良好的设计模式和依赖注入和设计单元可测试性对于实现良好的关注点分离（模块化设计的基石）大有帮助。

从小处开始，但要牢记大局。在设计系统的较大块（或模块）时，请确保它们具有尽可能少的重叠区域。每个模块几乎不应该对它们运行的环境做出任何假设，并且只服务于一个关注点。它需要从其对等方获得的任何服务都应该通过外部初始化显式提供（最好使用依赖注入将模块粘合在一起形成一个工作应用程序）。

如果您的架构是模块化的，那么将关注点分离到它们自己的部署单元中（以项目、jar、捆绑的形式）是一项简单的任务、插件、扩展或其他），您可以在部署期间开始轻松混合和匹配各种模块，以获得特定应用程序实例所需的确切功能集。这就是我所说的部署时间模块化的意思。

诸如之类的依赖注入框架在实现部署时间模块化方面大有帮助Guice、Spring 框架等。

运行时模块化我认为这类似于 Eclipse 和 NetBeans 插件或 Mozilla 扩展提供的模块化，您可以在部署/安装后更改应用程序模块的配置和设置。

这意味着某种架构和基础设施可以在应用程序初始化时或在运行时动态地识别新的插件/扩展。

后者还意味着所有模块的构建都必须隐含假设，即模块使用的任何服务都可以在任何时间点轻松消失，从而付出额外的努力来确保在这个不稳定的世界中运行的代码的稳健性。

The answer to Your question really depends on what did you mean by "modular".

There are several levels of concerns that you must consider when making your application modular.

First of all you must consider if the "modularity" you seek is architectural modlarity, deploymeyment time modularity or runtime modularity.

In any case every consecutive level implies all of the previous levels.

For starters - to make your application modular you have to start from architecture. Separate your concerns into well defined clean cut parts that have well defined interfaces to the "outside world". Use of good design patterns and dependency injection and designing for unit testability go a long way here towards achieving nice separation of concerns that is the bedrock of modular design.

Start from small but keep in mind the large picture. When designing a bit larger chunks (or modules) of your system make sure they have as few overlapping areas as possible. Every module should make almost no assumptions about the environment they run in and be serving only one single concern. Any services it requires from it's peers should be explicitly provided by external initialization (preferably using dependency injection for gluing the modules together into a working app).

If your architecture is modular, it is an easy task to separate the concerns into their own deployment units (in form of projects, jars, bundles, plug-ins, extensions or whatever) and you can start easily mixing and matching various modules during the deployment to get the exact feature set you need for the particular application instance. This is what I mean by deployment time modularity.

Going a long way towards enabling deployment time modularity are Dependency Injection frameworks like Guice, Spring framefork and others.

Runtime modularity the way I see this is something akin to the modularity provided by Eclipse and NetBeans plugins or Mozilla extensions where you can change the configuration and set of your application modules after the deployment/installation.

This implies some sort of architecture and infrastructure that recognizes new plug-ins/extensions either at application initialization time or dynamically at runtime.

Latter also means that all your modules must be build with implicit assumption that any service that a module uses can easily dissapear at any point in time, making the extra effort to ensure robustness of the code running in this volatile world.

回复收藏 0 原文