1

我刚开始使用Guice。
当我使用 Guice 时，我的应用程序类变得松散耦合。
使用 Google Guice 是否会降低代码的可读性、不清晰、更难理解和调试？
你对它的体验如何？

4

4 回答 4

4

我的经验一直是积极的。我的代码更具可读性；它在天文上更容易测试和维护。松散耦合是重点。

于 2012-04-04T21:12:26.567 回答
3

如果有人一般不熟悉依赖注入，那么是的，我认为它会使代码更难理解和理解......起初。例如，我第一次使用 Spring 时，至少可以说有点困惑。然而，一旦你理解了注入 bean 之类的概念，它就会变得有意义。

良好的设计至关重要，而 DI 对松散耦合和可测试性至关重要。

于 2012-04-04T21:13:52.173 回答
2

明智地使用依赖注入，无论是通过 Guice 还是其他方式，都可以使代码更容易测试并保持干净和松散耦合。它使测试替身（模拟对象等）的使用变得更加容易。

做得不好，或者走极端，它会使系统几乎无法理解——即使每个类可能孤立地很清楚，但很难说出类的组装是做什么的（尤其是在涉及大量 XML 配置文件的情况下！） . 一些系统似乎将 DI 配置本身用作一种编程语言，这很快就会变得难以管理。

于 2012-04-04T21:42:55.413 回答
2

哪个更容易阅读？

A：

public class ServiceCaller {
  private String url;
  private Service service;
  public A {
    url = System.getProperty("url);
    Hashtable env = ...;
    Context ctx = new InitialContext(...)
    service = ctx.lookup(...)
  }
  public String getValue() {
    return service.getValue();
  } ...

或者

public class ServiceCaller {
  private Service service;
  @Inject
  public ServiceCaller(Service service) {
    this.service = service;
  }
  public String getValue() { ...}

如果你不习惯 DI，你可能会说“#1”，因为你可以阅读所有的实现，并且确切地知道发生了什么，服务是什么等等。但问题是：从外部看类合同，你不知道里面发生了什么。#2 明确指出：“给我一个服务实例，我会给你一个值。你所要做的，就是相信有一个隐藏的机制会提供这个服务实例”。（Hidden=hidden，你需要在你的代码中有一个“getproperty-getcontext-getService-Module”）

所以在我看来：DI 更容易阅读（尽可能使用基于构造函数的注入）。它更容易测试，有些人可能会说，最好的文档是编写良好的、有效的测试。你只需要一点信心就可以相信会有一个服务实例......

于 2012-04-05T06:01:27.567 回答