자료 추상화
클래스의 자료는 추상적인 개념으로 표현하라.
단순히 자료를 감추고 조회/설정(get/set) 함수로 자료를 다루는 것은 좋은 클래스가 아니다. 또한 인터페이스를 제공한다고만 해서도 좋은 클래스는 아니다.
추상화된 인터페이스를 제공해서 사용자가 클래스 내부의 구현을 모른채로 사용할 수 있어야 좋은 클래스이다. 이를 위해 클래스의 자료를 추상적인 개념으로 표현해야 한다.
자료/객체 비대칭
- 객체는 추상화의 뒤로 자료를 숨기고 이를 다루는 함수만을 공개한다.
- 자료 구조는 자료를 그대로 공개하며 다루는 함수를 제공하지 않는다.
이 두 문장은 완벽한 반대의 모습을 취하고 있다. 반대라는 말을 다르게 하면 상호보완적이라는 의미가 된다.
절차적인 코드는 기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다. 객체 지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다.
반대로, 절차적인 코드는 새로운 자료 구조의 추가가 어렵다. 객체 지향 코드는 새로운 함수의 추가가 어렵다.
이 역시도 쉽게 풀면, 절차 지향 코드에서 어려운 변경은 객체 지향 코드에서는 쉽고, 그 반대도 성립한다라는 것이다.
코드를 작성하다가 새로운 자료 구조를 추가할 땐, 클래스와 객체 지향 코드 방식을 이용한다. 반대로 새로운 함수를 추가할 땐, 자료 구조와 절차 지향 코드 방식이 적합하다는 것이다.
디미터 법칙
디미터 법칙은 모듈은 자신이 조작하는 객체의 내부를 몰라야 한다는 것이다. 자료 추상화에서 언급했듯이 객체는 자료를 숨기고 추상화된 함수를 제공한다. 즉, 객체는 조회 함수(get)으로 내부 구조를 공개해서는 안된다는 것이다.
디미터 규칙은 다음의 규칙을 따릅니다.
"클래스
C의 메소드f는 다음과 같은 객체의 메소드만 호출해야한다.
- 클래스 C
- f가 생성한 객체
- f 인수로 넘어온 객체
- C 인스턴스 변수에 저장된 객체
이때, 위에서 허용하고있는 메소드가 반환하는 객체의 메소드는 호출하면 안된다. 즉, 친구의 친구는 안된다.
(ex. f가 생성한 객체의 메소가 반환한 객체가 CC라면 CC의 메소드는 호출하면 안된다.)
기차 충돌
방금 언급한 부분인
이때, 위에서 허용하고있는 메소드가 반환하는 객체의 메소드는 호출하면 안된다. 즉, 친구의 친구는 안된다.
(ex. f가 생성한 객체의 메소가 반환한 객체가 CC라면 CC의 메소드는 호출하면 안된다.)
이런 상황을 기차 충돌(train wreck)라고 부릅니다. 이러한 코드는 상당히 난잡하게 보이므로 피하는 것을 권장하고 있다.
예를들어, 아래와 같은 자바 코드가 기차 충돌 코드이다.
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
/*
* getOptions()가 반환하는 객체의 메소드인 getScracthDir()을 호출하고,
* 이 메소드가 반환한 객체의 메소드인 getAbsolutePath()를 호출하고 있다.
*/잡종 구조
위 코드처럼 조회 함수를 마구 사용하다보면 자료 구조와 객체가 섞인 잡종 구조가 발생한다. 이런 잡종 구조엔 중요한 기능을 수행하는 함수, 조회/설정 함수 등이 섞이게 된다. 이때, 조회/설정 함수는 비공개 변수를 노출하게 되므로 이러한 비공개 변수를 외부로 노출시킬 가능성이 생기게 된다.
이런 잡종 구조는 새로운 함수나 자료 구조를 추가하기 어렵다. 이 구조는 각 상황의 단점들만을 모은 구조이므로 가능한 피하는게 좋다.
구조체 감추기
자료 전달 객체
자료 구조체는 전형적으로 공개 변수만 있고 함수는 없는 클래스이다. 이런 자료 구조체를 자료 전달 객체(DTO, Data Transfer Object)라고 한다.
DTO는 주로 DB와 통신이나 소켓에서 받은 메세지의 구문 분석에 주로 사용된다.
bean 구조
일반적인 형태로 bean 구조라는 형태가 있다. 빈 구조는 공개 변수를 조회/설정 함수로 조작한다.
활성 레코드
활성 레코드는 DTO의 특수한 형태이다. 공개 변수가 있거나 비공개 변수에 조회/설정 함수를 가진 자료구조이다. 여기에 더해 save나 find같은 탐색 함수도 제공하기도 한다.
활성 레코드에 비즈니스 규칙 메소드를 추가하게 되면 잡종 구조가 되어버리기 때문에 바람직하지 않다. 이에 대한 해결책으로 활성 레코드 자체를 자료 구조로 취급한다. 이렇게 비즈니스 규칙을 담으며 내부 자료를 숨기는 객체는 따로 생성한다.
후기
객체 지향 강의를 들을 때 귀에 못이 박히도록 들었던 말을 이번 장에서 제일 강조하고 있다.
사실 웹 개발자, 그 중에서도 프론트엔드 개발자를 지망하면서 JS와 리액트를 주로 다루다보니 클래스를 쓸 일이 거의 없었다. 물론 JS에도 객체 지향 개념이나, 클래스 명령이 있고 클래스를 공부하긴 했지만 실전에서 사용해본적은 솔직히 없었다.
이러한 경험 부족 때문에 이번 장은 상당히 짧았는데도 읽고 이해해나가는데 제법 시간이 소요 됐다.
