我已将monolitic Maven转换为可重复使用的多模块项目。我从原始项目中创建了三个项目。现在我遇到了一个问题。我正在创建一个新的应用程序，但我希望通过使用未来可能被其他项目使用的其他两个项目来实现。但是，可重用项目有自己的域类，但我需要在新应用程序中扩展它们的功能。可重用项目中的域类是通用的。
现在，在我创建的新应用程序中扩展这些类是唯一的选择吗？这不好吗？我拥有的一些类例如是Question。但是，这个类需要在我创建的应用程序中拥有更多功能。还有其他解决方案吗？
答案 0 :(得分：1)
现在，是在新应用程序中扩展这些类的唯一选择 我创造了什么？这不好吗？
在我看来，创建一个具有泛型类的模块是一个非常有效的解决方案，可以由使用该模块的应用程序进行扩展。这就是有多少框架的工作原理。您应该在适当的地方使用接口，但是您仍然需要在模块中保存通用（可能是抽象的）类以供应用程序扩展。
答案 1 :(得分：0)
就个人而言，我从不使用抽象类并仅限制使用扩展到接口。原因是类继承会产生一些非常混乱的代码。我花了几年时间才意识到，每次我使用类继承时，都会有一段时间我对这个决定感到后悔，并且不得不将它重构为一个不那么复杂和灵活的东西。所以如果你问你是否应该使用类继承，我的建议是：不，永远！无论你想解决什么问题。如果您的设计要求您使用继承，那么您的设计就会出现问题，需要重新考虑它。禁止继承，最终会得到更好的代码。
如果实现的数量大于1，则仅使用接口。此外，将您的交互分成很好的选择方法组。这使得它们更具可重用性。您可以实现多个类，而不像类，它们可以扩展其他接口。对于您的域类，您可能有一个Foo类，并且您需要一个非常相似但有一些额外方法的Bar类。换句话说，它部分是Foo，部分是其他东西。这是您可能想要使用接口表达的内容。
无论如何，您应该尽可能简化域类。基本上除了setter，getters，equals，hashCode和toString之外的任何东西都应该是禁止的。如果Java有结构，那就是你要使用的。我过去曾经处理过具有继承性的域模型，这不值得麻烦。它导致了数据库模式的混乱，映射代码等。这就是现在Java给它起了个坏名字的原因。
之前我曾经处理过多模块maven项目。在您意识到模块的数量不断增加之前，这似乎是一个好主意。一旦你有两个模块，你只需要花一点时间才能决定有三个模块。实际上，他们并没有真正提供很好的封装，因为你发现了这个小难题。您正在讨论通过至少两个模块拆分域类并使用继承进一步搞乱设计。这使得一些非常难看的代码和模块化方面的所有良好意图都被抛到了窗外。如果你有一个统一的代码库，你就可以重构域模型以适应两个用例。
在大企业中，模块结构往往反映组织层次结构，并导致组织驱动的架构。那是一件非常糟糕的事情。它使您的依赖关系管理，版本控制，发布计划变得复杂，导致冗长的构建，糟糕的设计，并且实际上阻碍了重用和有效协作（这可能与您想要实现的完全相反）。如果可以的话，将所有内容放回一个模块中并使用软件包进行模块化，并应用一些合理的规则，即不允许循环依赖（使用静态代码分析工具）和具有良好的测试覆盖率等内容。你的生活将变得更加简单。