객체와 자료 구조

객체지향 프로그래밍을 한다면 객체를 객체답게 볼 수 있어야 합니다. 또한 원하는 기능을 개발하기 위해 올바른 자료구조를 선택할 수 있어야 합니다. 이번 장을 통해 객체와 자료 구조에 대해 조금 더 다가가 보고자 합니다.

자료 추상화

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

    public double getX() {
        return this.x;
    }

    public double getY() {
        return this.y;
    }

    public void setX(double x) {
        this.x = x;
    }

    public void setY(double y) {
        this.y = y;
    }
}

단순히 필드를 드러내지 않는다고 해서 추상화가 이루어진 것은 아닙니다. 위의 클래스는 내부 필드에 직접적으로 접근할 수는 없지만, getter/setter 메서드를 통해 필드를 유추할 수 있습니다.

 

변수 사이 함수라는 계층을 단순히 추가한다고 구현이 감춰지지 않는다는 것을 의미합니다. 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 합니다.

 

인터페이스나 getter/setter 메서드만으로는 추상화가 이루어지지 않기에 객체가 포함하는 자료를 표현하는 가장 좋은 방법을 심각하게 고민해야 합니다.

자료/객체 비대칭

자료 구조를 사용하는 절차적인 코드는 새로운 함수를 추가하기는 쉽지만, 새로운 자료 구조를 추가하기 어렵습니다. 모든 함수에 변경이 필요하기 때문입니다.

 

객체 지향 코드는 새 클래스를 추가하기는 쉽지만, 새로운 함수를 추가하기 어렵습니다. 모든 클래스에 함수를 추가해야 하기 때문입니다.

객체 지향의 장점을 강조하며 공부하다 보니 이런 절차 지향에서 오는 장점을 잊고 있었습니다. 때로는 단순한 자료 구조와 절차적인 코드가 적합한 상황이 있음을 인지해야 합니다.

디미터 법칙

모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙입니다.

기차 충돌

final String result = wordfile.getDirectory().getFile().getWord().getText();

위와 같은 코드를 기차 충돌이라고 합니다. 한눈에 들어오지도 않고 조잡하기에 피하는 편이 좋습니다.

구조체 감추기

객체에서 값을 얻어서 사용하기보다는 객체의 역할에 맡게 임무를 넘겨야 합니다. 값을 받아 일일이 조작하는 것 자체가 어떤 값을 객체가 가졌는지 알고 있다는 행동이므로 내부를 숨기려는 객체의 본질적인 의미를 잃어버리게 됩니다.

자료 전달 객체

자료 구조체의 전형적인 형태는 공개 필드만 존재하고 메서드가 없는 클래스입니다. 이런 자료 구조체를 자료 전달 객체(Data Transfer Object)라 합니다.

 

메서드가 없음을 다시 한번 생각하고 넘어가야 합니다. 전달이 목적이지 비즈니스 로직이 들어가서는 안 됩니다. 비즈니스 규칙을 담으면서 내부 자료 구조를 숨기는 객체는 따로 생성해야 합니다.

마치며

시스템을 구현하고자 할 때 객체/자료구조 중 적합한 것으로 선택해서 사용해야 합니다. 이러한 유연성은 시스템에 확장성과 견고함을 더해줍니다.