我已将单体 Maven 转换为可重用的多模块项目。我从原始项目创建了三个项目。现在我遇到了一个问题。我正在创建一个新的应用程序，但我想通过使用其他两个项目来实现，这些项目将来可能会被其他项目使用。但是，可重用项目有自己的域类，但是我需要在新应用程序中扩展它们的功能。可重用项目中的领域类是通用的。
现在，在我创建的新应用程序中扩展这些类是唯一的选择吗？这很糟糕吗？例如，我的一些课程是Question。但是，这个类需要在我创建的应用程序中具有更多功能。还有其他解决方案吗？
问问题
178 次
2 回答
1
现在，在我创建的新应用程序中扩展这些类是唯一的选择吗？这很糟糕吗？
在我看来，创建一个具有泛型类的模块以供使用该模块的应用程序扩展是一个完全有效的解决方案。这就是有多少框架起作用。您应该在适当的情况下使用接口，但您仍然需要在模块中保存通用（可能是抽象的）类，以便由您的应用程序扩展。
于 2013-06-29T17:53:05.517 回答
0
就个人而言，我从不使用抽象类，并且仅将扩展的使用限制为接口。原因是类继承会产生一些非常混乱的代码。我花了几年的时间才意识到，每次我使用类继承时，都会有那么一刻我后悔那个决定，不得不将它重构为不那么复杂和更灵活的东西。所以如果你问你是否应该使用类继承，我的建议是：不，永远不要！无论您要解决什么问题。如果您的设计要求您使用继承，那是您的设计存在问题，您需要重新考虑它。禁止继承，你会得到更好的代码。
仅当实现的数量将大于 1 时才使用接口。此外，将您的接口拆分为很好的选择方法组。这使它们更加可重用。您可以实现多个，并且与类不同，它们可以扩展其他接口。对于您的域类，您可能有一个 Foo 类，并且您想要一个非常相似但有一些额外方法的 Bar 类。换句话说，它部分是 Foo，部分是其他东西。这就是您可能想要使用接口来表达的东西。
无论如何，您应该使域类尽可能简单。基本上，除了 setter、getter、equals、hashCode 和 toString 之外的任何东西都应该禁止使用。如果 Java 有结构，那么您将使用它。我过去处理过带有继承的域模型，这不值得麻烦。它会导致数据库模式、映射代码等错综复杂的混乱。这就是如今 Java 名声不佳的原因。
我之前处理过多模块 maven 项目。一开始这似乎是一个好主意，直到您意识到模块的数量不断增加。只要您拥有两个模块，只需片刻即可决定拥有三个模块。实际上，它们并没有真正提供很好的封装，因为您正在发现这个小困境。您正在谈论将域类拆分为至少两个模块，并通过使用继承进一步弄乱设计。这使得一些非常丑陋的代码和你所有关于模块化的好意都消失了。如果您有一个统一的代码库，您将重构域模型以在正确的位置适应这两个用例。
在大企业中，模块结构往往反映组织层次结构，并导致组织驱动的架构。这是一件非常糟糕的事情。它使您的依赖管理、版本控制、发布计划变得复杂，导致构建冗长、设计糟糕，并且实际上阻碍了重用和有效协作（这可能与您想要实现的目标完全相反）。如果可以的话，将所有内容放回一个模块中并使用包进行模块化，并应用一些关于不允许循环依赖（使用静态代码分析工具）和具有良好测试覆盖率之类的合理规则。你的生活会简单很多。
于 2013-06-29T23:14:09.737 回答