java - 可维护、可扩展和模块化实际上意味着什么？

Question

当我在任何文章/书籍中读到它将使您的应用程序可维护、可扩展和模块化时，这实际上意味着什么。

我对它们确实有模糊的理解，但我很清楚它们的实际含义。例如:- 我多次听说/读到 mvc 架构使应用程序更具可维护性、可扩展性和模块化。这是我的理解:-

可维护:-如果我们需要适应微小的变化/或一些缺陷，很容易处理。此外，代码应该是可单元测试的。在 MVC 世界之前， View 、 Controller 和模型角色由 servlet 扮演。因此很难适应任何改变。也很困难从单元测试的角度来看

可扩展:-应用程序如何响应用户负载的增加。

模块化:-对我来说，这个术语看起来非常抽象。模块化是将应用程序分解为模块可以由独立团队开发，互不影响。可以根据其他因素进行分解，例如可重用性、功能明智，以便子团队可以独立工作、可测试性。

现在 MVC 如何使代码模块化。也许是因为团队可以独立处理 View 、 Controller 和模型。

如果我在某些地方错了或者我遗漏了任何重要方面，请纠正我

Answer 1

• 可维护:除了您提到的之外，可维护的系统还意味着进行重大更改不应该成为问题(显然这取决于变化本身的大小)。也就是说，如果客户想要对整个UI层进行彻底改造，那么，这样做就意味着你不需要重写一半的业务逻辑和数据层。

• 可扩展:并非如此。如果应用程序能够容纳越来越多的用户而不对其执行能力产生任何重大影响，那么它就可以很好地扩展。如果您的应用程序为 1000 个用户处理请求的时间在 10 毫秒以下，但为 2000 个用户处理请求的时间为 1000 毫秒，那么您的应用程序可能无法很好地扩展。可扩展性通常是通过巧妙的设计来实现的，它允许巧妙地使用资源，例如数据库连接和缓存等其他机制，这可以减少繁重操作的使用。

• 模块化:不完全是。如果应用程序是松散耦合但紧密结合的，那么它就是模块化的。这意味着模块彼此独立，但它们可以很好地协同工作。因此，按照我之前的示例，如果您以模块化方式构建应用程序，则在 UI 层中进行更改不应影响您的业务层，反之亦然。

根据此声明:

Now how MVC makes the code modular. Probably becoz team can work independently on views, controller and models.

我认为 MVC 可以更轻松地将系统分解为模块。话虽这么说，我不认为如果一个系统不使用 MVC，那么该系统就不是模块化的等等。您可能会遇到使用 MVC 模式构建的应用程序，但维护起来却是一场噩梦，反之亦然.