如何实现软件项目的模块化
实现极其松散耦合的最佳方法是什么？
如果您想将您的软件模块化到如此极端的程度，以至于没有任何部分依赖于系统中的任何其他部分，但它们仍然能够通信，这意味着我们必须使用（与技术无关的）来实现这一目标，那么
请提出建议，将其视为一次头脑风暴......:)
What are the best ways to achieve extremely loosely coupling?
If you want to modularize your Software to such an extreme extent that no parts are relying upon any other parts in your system, but they would still be able to communicate, which means would we have to use (technology agnostic) to achieve this goals then
Suggestions please, think of this as a brainstorm ... :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
数据。
如果你想要松耦合，答案就是数据。 您的程序或组件不会相互“执行功能”，它们会相互传递数据。 （在内部，这可能通过调用方法来完成 - 但除了机制之外，从概念上讲，它应该是传递数据）。
如果流程中的数据被视为不可变，那就更好了。
这提供了清晰的组件边界，并在很大程度上保护您免受突然发生的变化（因为您可以相对轻松地将一种形式的数据转换为另一种形式）。 它还可以轻松地传输到多进程或网络应用程序，因为数据传递的语义在任何地方都是相同的 - 在不传递一些新数据的情况下，不存在神奇的隐藏状态更改的假设。
定义良好的传递数据的接口，你就是黄金。 我指的是数据，而不是知道如何做各种神奇事情的“对象”。 只是简单、纯粹的数据。
顺便说一句 - 这并不是说对象在您的程序中没有一席之地 - 它们是对您的数据起作用的东西。
另外，请确保程序中处理数据的部分与负责实际传输数据的部分以及向用户显示数据的部分分开。 我知道，这就是“将业务逻辑与持久性和 UI 层分开”的全部内容。
Data.
If you want to be loosely-coupled, the answer is data. Your programs or components will not "execute functions" on each other, they will pass data to each other. (Internally, this will probably be done by calling a method - but the mechanics aside, it should be, conceptually, passing data).
If the data, inside your process, is treated as immutable, even better.
This gives clear component boundaries, and protects, to a great extent, from changes blowing up on you (as you can transform one form of data into another relatively easily). It also makes it easy to transfer to multi-process or networked applications, as the semantics of data passing are the same everywhere - there's no assumption of magical hidden state changes without passing some new piece of data.
Well-defined interfaces that pass data, and you're golden. And I do mean data - not 'objects' that know how to do all kinds of magic things. Just simple, pure data.
By the way - that's not saying that objects don't have a place in your program - they're the things that act on your data.
Also, make sure that you keep the parts of your program that deal with the data separate from the parts of the program that are responsible for actually shuttling it around, and the parts that show it to the user. I know, it's that whole 'keep your business logic separate from your persistence and UI layer' stuff again.
使用一些与域无关的数据格式来实现模块之间的通信或交换信息，例如 XML、RPC、HTTP 等。
让不同的团队开发不同的模块，而不让他们互相交谈或协调他们的工作。 给他们设定一个目标，设计一个具有通用接口的统一模块，以便以后在各种系统中以各种角色使用（当然，在模块的功能范围内）。
Use some domain-detached data format to enable communication or exchange information between modules, like XML, RPC, HTTP etc.
Let different teams develop different modules without letting them talk to each other or coordinate their efforts. Set them a goal to design a unified module with a generalistic interface to be later used in various systems in various roles (within the function scope of the module, of course).
使用控制反转框架，以便组件不必知道如何加载其依赖项。
Use an Inversion of Control framework so that components don't have to know how to load their dependencies.
我觉得你说的这个是不可能实现的，或者即使可以实现，也比较难实现，而且没有什么优势。
模块化可能很好，但也有局限性。 当然，你可以设计你的系统，使某些部分依赖于 API，但不依赖于特定的实现，我鼓励这样做，但“绝对不依赖”是一种幻想。 “沟通”很可能会产生依赖性。
尝试将软件模块化是件好事，但你已经走得太远了。
I think what you're mentioning can not be implemented or even if it can, it would be rather hard to implement and it'd have few advantages.
Modularization can be good, but there are limits. Of course, you can design your system so that some parts depend on APIs, but not specific implementations, and I'd encourage that, but "absolutely no dependencies" is an illusion. "communication" would most likely create dependencies.
It is good to try to modularize software, but you're going too far.
让每个系统将其功能公开为 REST 或 WS-* 接口。
然而，一个更有趣的问题是你什么时候想这样做？ 您需要从您选择的技术中榨取尽可能多的生产力/性能，这意味着使用特定于技术的解决方案。
Have each system expose it's functionality as a REST or WS-* interface.
However, a more interesting question is when would you want to do this? You need to squeeze as much productivity / performance out off the technology that you have choosen, which means using technology specific solutions.
我认为做到这一点的唯一方法是某种形式的“白板”系统，其中组件在一些通常可访问的区域中写下事实，并观察其他组件写下他们的事实。 这种架构用于分布式人工智能系统，但我从未听说过现实世界的分布式系统使用它们。 您的组件显然需要就“白板”消息的格式和实际实现达成一致，例如共享内存。
I think the only way to do this is a some form of "whiteboard" system, where components write down facts in some commonly accessible area and observe other components writing down their facts. Such architectures are used in distributed AI systems, but I've never heard of real-world distributed systems using them. Your components would obviously need to agree a format for the "whiteboard" messages, and an actual implementation, such as shared memory.
实现 100% 模块化可能非常困难，不值得付出努力。 对于应用程序中的类，您可以使用依赖注入和控制反转来松散耦合。
如果您正在谈论一种更加分布式的系统方法，您可以使用 SOAP 或 REST（REST 是技术上最中立的一种），以便每个模块都提供一个契约，但在这种情况下，您将需要某种集中式消息传递/路由系统知道模块在哪里及其合同，以便可以调用它们并实现某种标准通信来报告成功/失败，除非当您的模块通信时您希望它进入黑洞而再也不会被听到:)
请记住，概括得越多，调试、维护、理解就越困难，如果您的应用程序需要任何性能，这些方法将是您可能做的最慢的事情。
To be 100% modular is likely hard enough to not be worth the effort. For classes in an application, you can use Dependency Injection and Inversion of Control to loosely couple.
If you're talking about a more distributed system approach you can use SOAP or REST (REST being the most technologically neutral one) so that each module provides a contract, but in that case you're going to need some sort of centralized messaging/routing system that knows where the modules are and their contracts so that they can be called and implements some kind of standard communication for reporting success/failure, unless when your modules communicate you want it to go into a black hole to never be heard from again :)
Just remember the more you generalize, the more difficult it will be to debug, maintain, understand, and if your application requires any sort of performance these methods will be some of the slowest things you can likely do.