Clean Code - 객체와 자료 구조

변수를 비공개(private)로 정의하는 이유가 있다.
남들이 변수에 의존하지 않게 만들고 싶어서다.
그렇다면 어째서 조회(get) 함수와 설정(set) 함수를 당연하게 공개(public)해 비공개 변수를 외부에 노출할까?

자료 추상화

• 구체적인 Point 클래스

public class Point {
	public double x;
    public double y;
}

• 추상적인 Point 클래스

public interface Point {
	double getX();
    double getY();
    void setCartesian(double x, double y);
    double getR();
    double getTheta();
    void setPolar(double r, double theta);
}

추상적인 클래스는 직교좌표계를 사용하는지 극좌표계를 사용하는지 알 길이 없다. (둘 다 아닐지도 모른다!)
그럼에도 불구하고 인터페이스는 자료구조를 명백하게 표현한다.
클래스 메서드가 접근 정책을 강제한다.
좌표를 읽을 때는 각 값을 개별적으로 읽어야 한다. 하지만, 좌표를 설정할 때는 두 값을 한꺼번에 설정해야 한다.

반면, 구체적인 클래스는 확실히 직교좌표계를 사용한다.
또한, 개별적으로 좌표값을 읽고 설정하게 강제한다.
이는 구현을 노출한다. 변수를 private으로 선언하더라도 각 값마다 조회(get) 함수와 설정(set) 함수를 제공한다면 구현을 외부로 노출하는 셈이다. (변수 사이에 함수라는 계층을 넣는다고 구현이 저절로 감춰지지는 않는다.)
구현을 감추려면 추상화가 필요하다!

• 구체적은 Vehicle 클래스

public interface Vehicle {
	double getFuelTankCapacityInGallons();
    double getGallonsOfGasoline();
}

• 추상적인 Vehicle 클래스

public interface Vehicle {
	double getPercentFuelRemaining();
}

자료를 세세하게 공개하기 보다는 추상적인 개념으로 표현하는 편이 좋다.
인터페이스나 조회/설정 함수만으로는 추상화가 이뤄지지 않는다.
아무 생각 없이 조회/설정 함수를 추가하는 방법이 가장 나쁘다.

자료/객체 비대칭

• 객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다.
• 자료 구조는 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다.
• 두 정의는 본질적으로 상반된다. 사소한 차이로 보일지 모르지만 그 차이가 미치는 영향은 굉장하다.

public class Square {
	public Point topLeft;
    public double side;
}

public class Rectangle {
	public Point topLeft;
    public double height;
    public double width;
}

public class Circle {
	public Point center;
    public double radius;
}

public class Geometry {
	public final double PI = 3.141592653589793;
    
    public double area(Object shape) throws NoSuchShapeException {
    	if (shape instanceof Square) {
        	Square s = (Square) shape;
            return s.side * s.side;
        }
        else if (shape instanceof Rectangle) {
        	Rectangle r = (Rectangle) shape;
            return r.height * r.width;
        }
        else if (shape instanceof Circle) {
        	Circle c = (Circle) shape;
            return PI * c.radius * c.radius;
        }
        throw new NoSuchShapeException();
    }
}

• 절차 지향적인 도형 클래스

만약 Geometry 클래스에 둘레 길이를 구하는 perimeter() 함수를 추가하고 싶다면?
도형 클래스는 아무 영향도 받지 않는다. (도형 클래스에 의존하는 다른 클래스도 마찬가지)
반대로 새 도형을 추가하고 싶다면?
Geometry 클래스에 속한 함수를 모두 고쳐야 한다.

• 객체 지향적인 도형 클래스

area()는 다형 메서드이다.
Geometry 클래스는 필요 없다.
그러므로 새 도형을 추가해도 기존 함수에 아무런 영향을 미치지 않는다.
반면, 새 함수를 추가하고 싶다면 도형 클래스 전부를 고쳐야 한다.

public class Square implements Shape {
	private Point topLeft;
    private double side;
    
    double area() {
    	return side*side;
    }
}

public class Rectangle implements Shape {
	private Point topLeft;
    private double height;
    private double width;
    
    double area() {
    	return height * width;
    }
}

public class Circle implements Shape {
	private Point center;
    private double radius;
    public final double PI = 3.141592653589793;
    
    double area() {
    	return PI * radius * radius;
    }
}

• 절차적인 코드는 기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다. (새로운 자료구조를 추가하기 어렵다.)
• 반면, 객체 지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다. (새로운 함수를 추가하기 어렵다.)
• 분별 있는 프로그래머는 모든 것이 객체라는 생각이 미신임을 잘 안다.
• 때로는, 단순한 자료 구조와 절차적인 코드가 가장 적합한 상황도 있다.

디미터 법칙

• 디미터 법칙은 잘 알려진 휴리스틱으로, 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙이다.
• 앞 절에서 봤듯이, 객체는 자료를 숨기고 함수를 공개하낟. 즉, 객체는 조회 함수로 내부 구조를 공개하면 안 된다는 의미다.
• 그러면 내부 구조를(숨기지 안혹) 노출하는 셈이니까.
• 디미터 법칙은 "클래스 C의 메서드 f는 다음과 같은 객체의 메서드만 호출해야 한다." 고 주장한다.

1. 클래스 C
2. f가 생성한 객체
3. f인수로 넘어온 객체
4. C인스턴스 변수에 저장된 객체

• 하지만 위 객체에서 허용된 메서드가 반환하는 객체의 메서드는 호출하면 안 된다. (다시 말해, 낯선 사람은 경계하고 친구랑만 놀라는 의미)
• 다음 코드는 디미터 법칙을 어기는 듯이 보인다.

final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

기차 충돌

• 흔히 위와 같은 코드를 기차 충돌(train wreck)이라 부른다.
• 이어진 기차처럼 보이기 때문. (일반적으로 조잡하다 여겨지는 방식이므로 피하는 편이 좋다.)
• 위 코드는 아래와 같이 나누는 편이 좋다.

Options opts = ctxt.getOptions();
File scratchDir = opts.getScratchDir();
final STring outputDir = scratchDir.getAbsolutePath();

• 위 예제가 디미터 법칙을 위반하는지 여부는 ctxt, Options, ScratchDir이 객체인지 아니면 자료구조 인지에 달렸다.
• 객체라면 내부 구조를 숨겨야 하므로 확실히 디미터 법칙을 위반한다.
• 반면, 자료 구조라면 당연히 내부 구조를 노출하므로 디미터 법칙이 적용되지 않는다.
• 그런데 위 예제는 조회 함수를 사용하는 바람에 혼란을 일으킨다.
• 코드를 다음과 같이 구현했다면 디미터 법칙을 거론할 필요가 없어진다.

final String outputDir = ctxt.options.scratchDir.absolutePath;

• 자료 구조는 무조건 함수 없이 공개 변수만 포함하고 객체는 비공개 변수와 공개 함수를 포함한다면, 문제는 훨씬 간단하리라.
• 하지만, 단순한 자료구조에도 조회 함수와 설정 함수를 정의하라 요구하는 프레임워크와 표준이 존재한다.

잡종 구조

• 이런 혼란으로 절반은 객체, 절반은 자료 구조인 잡종 구조가 나온다.
• 이런 잡종 구조는 새로운 함수는 물롱니고 새로운 자료 구조도 추가하기 어렵다.

구조체 감추기

• 만약 ctxt, options, scratchDir이 진짜 객체라면?
• 그렇다면 앞서 코드 예제처럼 줄줄이 사탕으로 엮어서는 안 된다.
• 객체라면 내부 구조를 감춰야 하니까,

ctxt.getAbsolutePathOfScratchDirectoryOption();

ctx.getScratchDirectoryOption().getAbsolutePath();

• 첫 번째 방법은 ctxt 객체에 공개해야 하는 메서드가 너무 많아진다.
• 두 번째 방법은 getScratchDirectoryOption()이 객체가 아니라 자료 구조를 반환한다고 가정한다.
• 어느 방법도 썩 내키지 않는다.

• ctxt가 객체라면 뭔가를 하라고 말해야지 속을 드러내라고 말하면 안 된다.
• 다음은 같은 모듈에서 가져온 코드다.

String outFile = outputDir + "/" + className.replace('.', '/') + ".class";
FileOutputStream fout = new FileOutputStream(outFile);
BufferedOutputStream bos = new BufferedOutputStream(fout);

• 추상화 수준을 뒤섞어 놓아 다소 불편하다
• 임시 디렉터리의 절대 경로를 얻으려는 이유가 임시 파일을 생성하기 위한 목적이라는 사실이 드러난다.
• 그렇다면 ctxt 객체에 임시 파일을 생성하라고 시키면 어떨까?

BufferedOutputStream bos = ctxt.createScratchFileStream(classFileName);

• ctxt는 내부 구조를 드러내지 않으며, 모듈에서 해당 함수는 자신이 몰라야 하는 여러 객체를 탐색할 필요가 없다.
• 따라서 디미터 법칙을 위반하지 않는다.

자료 전달 객체

• 자료 구조체의 전형적인 형태는 공개 변수만 있고 함수가 없는 클래스다.
• 이런 자료 구조체를 때로는 자료 전달 객체(Data Transfer Object, DTO)라 한다.

활성 레코드

• 활성 레코드는 DTO의 특수한 형태다.
• 공개 변수가 있거나 비공개 변수에 조회/설정 함수가 있는 자료 구조지만, 대개 save나 find와 같은 탐색 함수도 제공한다.
• 활성 레코드는 DB 테이블이나 다른 소스에서 자료를 직접 변환한 결과다.
• 불행히도 활성 레코드에 비즈니스 규칙 메서드를 추가해 이런 자료 구조를 객체로 취급하는 개발자가 흔하다.
• 하지만, 이는 바람직하지 않다. (그러면 자료 구조도 아니고 객체도 아닌 잡종 구조가 나오기 때문)
• 해결책은 활성 레코드는 자료 구조로 취급한다.
• 비즈니스 규칙을 담으면서 내부 자료를 숨기는 객체는 따로 생성한다.

결론

객체는 동작을 공개하고 자료를 숨긴다.
그래서 기존 동작을 변경하지 않으면서 새 객체 타입을 추가하기는 쉬운 반면, 기존 객체에 새 동작을 추가하기는 어렵다.
자료 구조는 별 다른 동작 없이 자료를 노출한다.
그래서 기존 자료 구조에 새 동작을 추가하기는 쉬우나, 기존 함수에 새 자료 구조를 추가하기는 어렵다.
(어떤) 시스템을 구현할 때, 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 더 적합하다.
다른 경우로 새로운 동작을 추가하는 유연성이 필요하면 자료 구조와 절차적인 코드가 더 적합하다.