java - 向现有应用程序添加 guice

Question

我想在具有遗留代码的现有应用程序中开始使用 guice。是否有关于如何开始这样做的任何指示和 BKM？我找到了一种方法 here ，并希望获得更多信息和详细信息。
谢谢!

编辑:关于我的应用程序的更多详细信息:它是一个服务器应用程序，在自制服务器应用程序中运行，因此不涉及图形用户界面。它有很多遗留代码，我怀疑是否/如何迁移它。

Answer 1

您的策略取决于您现在的应用程序是如何构建的。如果您过度使用单例或其他一些框架。我已经完成了很多从无框架到 Spring 或 Guice 之类的应用程序的移植工作。这不是一项容易的任务，您在这方面的成功程度在很大程度上取决于代码量、团队中的人数以及团队对构建应用程序的新方法的接受程度。如果您没有从您的团队那里购买，那么我会在尝试编码之前从那里开始。说服人们相信您对应用程序的看法，回答他们的问题，让他们在头脑中进行一些设计，并欢迎他们的意见。如果他们有很大的顾虑，请让他们说出来，如果您没有解决方案，请承认，然后回去设计一个，然后提出来。重复此操作，直到所有人都参与进来。

现在移植代码。这取决于您拥有的应用程序类型:基于 Web、桌面等。但是，通常当我移植这些东西时，我会创建一个空项目，并按照您与团队设计的方式进行设置。然后开始将长生命周期的对象拉到容器中。单例是很好的起点，因为它们通常在应用程序的整个过程中都存在。开始在容器中实例化它们而不是它们的 getInstance() 方法。您可能不得不打破单例模式并公开它们的构造函数，但最终您想要摆脱单例。您可以保留静态引用。当您将对象从使用 getInstance() 重构为使用通过实例变量/getter/setter 提供的引用时，将它们重构。

慢慢地，您应该能够从 Guice 容器中执行您的应用程序。也许此时您只移植了应用程序的一部分。保持一个接一个地移植部分，并在容器中测试它们。此时您已经有了足够的基础，您可以从其他团队成员那里寻求帮助。最终您将移植整个应用程序，现在您可以开始重构它的一部分以按照 Guice 方式工作。返回并尽可能消除对 getInstance() 的静态引用和调用。

我一直发现设置骨架并进行移植比就地重构是处理这些类型转换的更有效方法。全面停止新工作也很重要，它最终会让你省去很多心痛。我试过不停止新工作，这些类型的转换可能会拖延到许多版本，因为团队继续以遗留方式编写新代码。有时，在下一个版本的实际工作开始之前的间歇期，在新版本之后开始可以给你额外的提升，这样你就可以到达其他成员可以帮助你移植的地步，因为你已经放下了框架。

也要记住管理。如果他们只需要新功能，您将很难控制团队。如果他们不认同你的努力，他们就会很难完成。