Кодова база, над якою я працюю, часто використовує змінні екземпляри для обміну даними між різними тривіальними методами. Оригінальний розробник переконаний, що він дотримується кращих практик, зазначених у книзі « Чистий код» дядька Боб / Роберта Мартіна: «Перше правило функцій - це те, що вони повинні бути маленькими». і "Ідеальна кількість аргументів для функції дорівнює нулю (niladic). (...) Аргументи важкі. Вони забирають багато концептуальної сили".
Приклад:
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);
}
}Це коротше, воно виключає неявну зв'язок даних між різними тривіальними методами і обмежує змінні області застосування до мінімально необхідного. Але, незважаючи на ці переваги, я все ще не можу переконати оригінального розробника, що цей рефакторинг є виправданим, оскільки, здається, він суперечить звичаям дядька Боба, згаданих вище.
Звідси мої запитання: Яке об'єктивне наукове обгрунтування на користь локальних змінних перед змінними екземплярів? Я не можу, здається, покласти свій палець на це. Моя інтуїція підказує мені, що приховані муфти погані і що вузька сфера краще, ніж широка. Але що це за наука, що підтверджує це?
І навпаки, чи є якісь недоліки цього рефакторингу, які я, можливо, не помітив?