是否比实例变量更喜欢局部变量？

public class SomeBusinessProcess {
  @Inject private Router router;
  @Inject private ServiceClient serviceClient;
  @Inject private CryptoService cryptoService;

  private byte[] encodedData;
  private EncryptionInfo encryptionInfo;
  private EncryptedObject payloadOfResponse;
  private URI destinationURI;

  public EncryptedResponse process(EncryptedRequest encryptedRequest) {
    checkNotNull(encryptedRequest);

    getEncodedData(encryptedRequest);
    getEncryptionInfo();
    getDestinationURI();
    passRequestToServiceClient();

    return cryptoService.encryptResponse(payloadOfResponse);
  }

  private void getEncodedData(EncryptedRequest encryptedRequest) {
    encodedData = cryptoService.decryptRequest(encryptedRequest, byte[].class);
  }

  private void getEncryptionInfo() {
    encryptionInfo = cryptoService.getEncryptionInfoForDefaultClient();
  }

  private void getDestinationURI() {
    destinationURI = router.getDestination().getUri();
  }

  private void passRequestToServiceClient() {
    payloadOfResponse = serviceClient.handle(destinationURI, encodedData, encryptionInfo);
  }
}

public class SomeBusinessProcess {
  @Inject private Router router;
  @Inject private ServiceClient serviceClient;
  @Inject private CryptoService cryptoService;

  public EncryptedResponse process(EncryptedRequest encryptedRequest) {
    checkNotNull(encryptedRequest);

    byte[] encodedData = cryptoService.decryptRequest(encryptedRequest, byte[].class);
    EncryptionInfo encryptionInfo = cryptoService.getEncryptionInfoForDefaultClient();
    URI destinationURI = router.getDestination().getUri();
    EncryptedObject payloadOfResponse = serviceClient.handle(destinationURI, encodedData,
      encryptionInfo);

    return cryptoService.encryptResponse(payloadOfResponse);
  }
}

#1 楼

偏爱局部变量而不是实例变量的客观科学依据是什么？

作用域不是二进制状态，而是梯度。您可以按从大到小的顺序对它们进行排序：据我所知，它们是同义词，但是我是C＃开发人员，而不是Java开发人员。为了简洁起见，我将所有静态变量归入全局类别，因为静态变量不是问题的主题。
范围越小越好。这样做的理由是，变量应处于尽可能小的范围内。这样做有很多好处：

它使您可以考虑当前班级的责任并帮助您坚持SRP。
它使您不必避免全局命名冲突，例如如果两个或多个类具有Name属性，则不必强迫它们像FooName，BarName一样为它们加上前缀...这样就可以使变量名尽可能简洁明了。变量（例如，用于Intellisense）与上下文相关的变量。
它启用某种形式的访问控制，这样您的数据就不会被您不认识的某个参与者操纵（例如，同事开发的另一个类）。
使代码更易读，因为您确保这些变量的声明尽量保持与这些变量的实际用法尽可能接近。通常表示开发人员不太了解OOP或如何实现它。看到范围广泛的变量是一个危险信号，表明OOP方法可能存在问题（无论是一般开发人员还是特定代码库）。
（凯文评论）使用当地人会迫使您以正确的顺序做事。在原始的（类变量）代码中，您可能错误地将passRequestToServiceClient()移动到方法的顶部，并且仍然可以编译。对于本地人，只有传递了未初始化的变量，您才可能犯该错误，这很明显很明显，您实际上并没有这么做。要说服原始开发人员相信这种重构是有必要的，因为它似乎与上述Bob叔叔的做法相矛盾。
相反，我可能忽略了这种重构的不利之处吗？

这里的问题是您对局部变量的参数是有效的，但是您还进行了其他更改，这些更改不正确，并导致建议的修复程序无法通过气味测试。 ”的建议，这是有好处的，实际上您也删除了这些方法，这是完全不同的。这些方法应该保留下来，而应该更改它们以返回其值而不是将其存储在类变量中：

Global > Class > Local (method) > Local (code block, e.g. if, for, ...)

我确实同意您在process方法中所做的事情，但是您应该一直在调用私有子方法，而不是直接执行它们的主体。即使您当前不重用方法，也要在相关的地方创建子方法，即使只是为了提高代码的可读性，也是一个好习惯。
不管局部变量参数如何，我立即注意到您的建议该修复程序比原始修复程序的可读性差得多。我确实承认，肆意使用类变量也会降低代码的可读性，但是与将所有逻辑都堆叠在一个（现在很复杂）的方法中相比，乍一看并没有。

#2 楼

原始代码使用诸如参数之类的成员变量。当他说要​​最小化参数的数量时，他真正的意思是要最小化方法运行所需的数据量。将数据放入成员变量并没有任何改善。

#3 楼

其他答案已经很好地解释了局部变量的好处，因此剩下的只是您的问题的一部分：

尽管有这些好处，我仍然似乎无法说服原始开发人员这种重构是有必要的，因为它似乎与上述鲍伯叔叔的作法相矛盾。

这应该很容易。只需将他指向Bob叔叔的Clean Code中的以下引用：

没有副作用
副作用是谎言。您的函数可以做一件事，但也可以做其他隐藏的事情。有时，它会对其类的变量进行意外更改。有时它将使它们成为传递给函数的参数或系统全局变量。无论哪种情况，它们都是曲折的和破坏性的误解，通常会导致奇怪的时间耦合和顺序依赖性。
（省略示例）
这种副作用会造成时间耦合。也就是说，只能在特定时间（换句话说，可以安全地初始化会话）调用checkPassword。如果调用顺序混乱，则会话数据可能会意外丢失。时间耦合令人困惑，尤其是当隐藏为副作用时。如果必须具有时间耦合，则应在函数名称中明确指出。在这种情况下，我们可能会重命名函数checkPasswordAndInitializeSession，尽管这肯定违反了“做一件事”。

，鲍勃叔叔不仅说一个函数应该带有很少的参数，他还说函数应尽可能避免与非本地状态进行交互。

#4 楼

“这与某人叔叔的想法相矛盾”从来都不是一个好论点。决不。不要从叔叔那里汲取智慧，请自己考虑。

也就是说，实例变量应该用于存储实际上需要永久或半永久存储的信息。这里的信息不是。没有实例变量，这很简单，因此可以使用它们。

测试：为每个实例变量编写文档注释。您能写出并非完全没有意义的东西吗？并向四个访问者写文档注释。他们同样毫无意义。

最糟糕的是，假定使用解密更改的方法，因为您使用了不同的cryptoService。不必更改四行代码，而必须用不同的变量替换四个实例变量，用不同的变量替换四个getter，并更改四行代码。

但是，如果您按代码行付费，则当然最好使用第一个版本。 31行而不是11行。如果要调试某些东西，则需要写三行，并且可以永久维护，以便在调试某些内容时进行读取，可以在需要更改时进行修改，如果您支持第二个cryptoService，则可以复制三行。

（缺少要点，即使用局部变量会强制您以正确的顺序进行调用）。

#5 楼

与实例变量相比，偏爱局部变量的客观科学依据是什么？我似乎不太愿意把手指放在上面。我的直觉告诉我，隐藏的耦合不好，而狭窄的范围要比广泛的范围好。但是支持这种科学的科学方法是什么？比对象本身。似乎尚未涵盖的做出这种区分的一些原因围绕并发性和可重入性。如果方法通过设置实例变量的值来交换数据，则两个并发线程可以轻易地破坏彼此的实例变量值，从而产生间歇性的，难以发现的错误。遇到这些问题，因为依赖实例变量的数据交换模式很可能使方法不可重入。类似地，如果使用相同的变量在不同的方法对之间传递数据，则存在即使执行非递归方法调用链的单个线程也将陷入围绕所涉及实例变量的意外修改而引起的错误的风险。

为了在这种情况下可靠地获得正确的结果，您需要使用单独的变量在每对方法之间进行通信，其中每一个方法调用另一个方法，或者要考虑到每个方法的实现它直接或间接调用的所有其他方法的所有实现细节。这很脆，并且缩放性很差。

#6 楼

就业务逻辑而言，仅讨论process(...)，您的同事的例子就清晰多了。相反，您的反例不仅仅需要粗略的浏览即可提取任何含义。

话虽如此，干净的代码既清晰又可读，而且质量很高-将局部状态推向更全球化的空间只是高层组装，因此质量为零。是的，编译器会生成它们，但重要的部分是它可以控制它们，从而使代码高效。同时也相对清晰易懂。

关于命名的一点。您需要有意义的最短名称，并在现有信息上进行扩展。即。 destinationURI，类型签名已经知道“ URI”。

#7 楼

我将完全删除这些变量和私有方法。这是我的重构：

public class SomeBusinessProcess {
  @Inject private Router router;
  @Inject private ServiceClient serviceClient;
  @Inject private CryptoService cryptoService;

  public EncryptedResponse process(EncryptedRequest encryptedRequest) {
    return cryptoService.encryptResponse(
        serviceClient.handle(router.getDestination().getUri(),
        cryptoService.decryptRequest(encryptedRequest, byte[].class),
        cryptoService.getEncryptionInfoForDefaultClient()));
  }
}

对于私有方法，例如router.getDestination().getUri()比getDestinationURI()更清晰易读。如果在同一课程中两次使用同一行，我什至会重复一遍。换句话说，如果需要getDestinationURI()，则它可能属于其他类，而不属于SomeBusinessProcess类。

对于变量和属性，通常需要持有稍后将使用的值。如果该类没有用于属性的公共接口，则它们可能不应该是属性。最糟糕的类属性使用可能是通过副作用在私有方法之间传递值。

无论如何，该类只需要执行process()，然后该对象将被丢弃，不需要将任何状态保留在内存中。进一步的重构潜力是将CryptoService从该类中删除。

基于评论，我想添加此答案是基于现实世界的实践。确实，在代码审查中，我首先要挑选的是重构类并移出加密/解密工作。一旦完成，然后我会问是否需要方法和变量，它们是否正确命名等等。最终的代码可能更接近于此：

public class SomeBusinessProcess {
  @Inject private Router router;
  @Inject private ServiceClient serviceClient;

  public Response process(Request request) {
    return serviceClient.handle(router.getDestination().getUri());
  }
}

使用上面的代码，我认为它不需要进一步的重构。与规则一样，我认为需要经验来知道何时以及何时不应用它们。规则并不是在所有情况下都适用的理论。另一方面，代码审查对一段代码可以通过多长时间具有真正的影响。我的诀窍是减少代码并使其易于理解。变量名可以作为讨论的重点，如果我可以删除它，那么审阅者甚至都不需要考虑它。

#8 楼

Flater的答案涵盖了范围界定的问题，但我认为这里还有另一个问题。
前者执行实际的业务逻辑，而后者通过添加更简单和更可重用的接口来节省类型并可能增加安全性。

在这种情况下，数据访问功能似乎并没有保存输入内容，并且不会在任何地方重复使用（否则删除它们还会有其他问题）。因此，这些功能根本不应该存在。

通过仅在命名函数中保留业务逻辑，我们可以兼得两者（在Flater的答案和imel96的答案之间的某个地方）：

public EncryptedResponse process(EncryptedRequest encryptedRequest) {

    byte[] requestData = decryptRequest(encryptedRequest);
    EncryptedObject responseData = handleRequest(router.getDestination().getUri(), requestData, cryptoService.getEncryptionInfoForDefaultClient());
    EncryptedResponse response = encryptResponse(responseData);

    return response;
}

// define: decryptRequest(), handleRequest(), encryptResponse()

#9 楼

首先也是最重要的一点：鲍勃叔叔有时似乎像一位传教士，但指出他的规则有例外。有几个相互冲突的规则。我个人认为4也可以。

使用实例变量时，它们应该构成一个连贯的类。这意味着，即使不是所有非静态方法，也应在许多方法中使用变量。 >我既不认为原始版本也不认为重构版本是最佳版本，@ Flater已经很好地说明了使用返回值可以做什么。它提高了可读性并减少了使用返回值的错误。

#10 楼

局部变量缩小了范围，因此限制了变量的使用方式，从而有助于防止某些类型的错误，并提高了可读性。

实例变量减少了函数的调用方式，帮助减少某些类型的错误，并提高可读性。 />，
TL; DR：我认为您闻到过多热情的原因是，热情过高。

#11 楼

尽管以get ...开头的方法不应返回void，但在第一个解决方案中给出了方法内抽象级别的分隔。尽管第二个解决方案的范围更广，但仍然很难对方法中发生的事情进行推理。这里不需要分配局部变量。我将保留方法名称，并将代码重构为类似以下内容：

public class SomeBusinessProcess {
  @Inject private Router router;
  @Inject private ServiceClient serviceClient;
  @Inject private CryptoService cryptoService;

  public EncryptedResponse process(EncryptedRequest encryptedRequest) {
    checkNotNull(encryptedRequest);

    return getEncryptedResponse(
            passRequestToServiceClient(getDestinationURI(), getEncodedData(encryptedRequest) getEncryptionInfo())
        );
  }

  private EncryptedResponse getEncryptedResponse(EncryptedObject encryptedObject) {
    return cryptoService.encryptResponse(encryptedObject);
  }

  private byte[] getEncodedData(EncryptedRequest encryptedRequest) {
    return cryptoService.decryptRequest(encryptedRequest, byte[].class);
  }

  private EncryptionInfo getEncryptionInfo() {
    return cryptoService.getEncryptionInfoForDefaultClient();
  }

  private URI getDestinationURI() {
    return router.getDestination().getUri();
  }

  private EncryptedObject passRequestToServiceClient(URI destinationURI, byte[] encodedData, EncryptionInfo encryptionInfo) {
    return serviceClient.handle(destinationURI, encodedData, encryptionInfo);
  }
}

#12 楼

两者都一样，并且性能差异不明显，因此我认为没有科学依据。然后归结为主观偏好。

我也倾向于比您的同事更喜欢您的方式。为什么？因为尽管有些书作者说了我的看法，但我认为它更易于阅读和理解。要阅读该代码，您需要在几个函数和成员变量之间来回切换。并非所有事物都凝聚在一个地方，您需要记住所有这些内容才能理解它。相比之下，这是一个更大的认知负担。

，您的方法将所有内容打包得更加密集，但并没有使它难以理解。您只需要逐行阅读它，就不需要记住那么多东西就可以理解它。可能正好相反。