Clean Code (객체와 자료구조)

자료 추상화

구현을 감추려면 추상적으로 구현해야한다.

public interface Vehicle {
	double getFuelTankCapacityInGallons();
    double getGallonsOfGasoline();
}
// 두 함수가 변수값을 읽어 반환할 뿐이라는게 뻔하다.

public interface Vehicle {
	double getPercentFuelRemaining();
}
// 정보가 어디서 오는지 전혀 드러나지 않는다.

후자가 더 좋은 코드다. 개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야하고, 아무 생각 없이 조회/설정 함수를 추가하는 것이 가장 나쁘다.

객체지향 vs 절차지향

객체지향 코드는 기존함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다.

절차지향 코드는 기존 자료구조를 변경하지 않으면서 새 함수를 추가하기 쉽다.

-> 객체지향이 항상 정답은 아니다. 상황에 맞게 사용할 수 있어야 한다.

디미터 법칙

객체에서 허용된 메서드가 반환하는 객체의 메서드는 호출하면 안된다.
(호출되는 객체는 내부구조를 드러내선 안되고, 모듈에서 자신이 몰라도 되는 함수를 탐색하지 않아야한다.)

final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
// 이런식의 코드를 기차충돌 코드라고 한다. 이렇게 사용하지 말고

Options opts = ctxt.getOptions();
File scratchDir = opts.getScratchDir();
final String outputDir = scratchDir.getAbsolutePath();
// 이런 식으로 나누는게 좋다. 허나 이것도 객체라면 내부구조를 숨기지 못했으므로 디미터법칙을 위반한다. 
//자료구조라면 디미터 법칙을 거론할 필요가 없다

final String outputDir = ctxt.options.scratchDir.absolutePath;
// 자료구조라면 이런식으로 구현하면 좋다.

BufferedOutputStream bos = ctxt,createScratchFileStream(classFileName);
// 임시 파일을 생성하여 객체로 디미터 법칙을 지켰다.

잡종구조

절반은 객체, 절반은 자료 구조인 잡종구조는 둘의 단점만 모아놓은 구조이다. 피하는게 좋다.