[클린코드] 6장. 객체와 자료구조

MEUN·2022년 3월 1일

< CLEAN-CODE />

목록 보기

9/17

2 주차

화 | Assignment #09

📚 6장. 객체와 자료구조

✔️ TIL

자료 추상화 (p.118)
- 자료를 세세하게 공개하기 보다는 추상적인 개념으로 표현하는 편이 좋다.
  예시) 자료의 수치를 그대로 공개하는 것이 아닌 퍼센트로 공개
- 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 하며, 아무 생각 없이 Getter/Setter 함수를 추가하지 않도록 해야 한다. (변수를 private으로 정의하는 데에는 이유가 있음)

자료/객체 비대칭 (p.118)
- 객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개하고,
  자료구조는 자료를 그대로 공개하며 별다른 함수를 제공하지 않는다.
- 절차적인 코드는 기존 자료 구조를 변경하지 않으면서 함수를 추가하기 쉽고,
  객체 지향 코드는 기존 함수를 변경하지 않으면서 클래스를 추가하기 쉽다.
- 무조건 객체 지향적인 코드만 작성할 것이 아니라, 상황에 따라 절차적인 코드를 적합하게 사용하기도 해야 한다.

디미터 법칙 (p.123)
- 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다.
- 객체에서 허용된 메소드가 반환하는 객체의 메소드는 호출하면 안된다. (체이닝처럼 연속으로 호출하면 안된다는 뜻)
- 기차 충돌 코드는 일반적으로 조잡하다 여겨지는 방식으로, 아래와 같이 행 단위로 끊어서 사용할 필요가 있다.
  하지만 아래 코드의 디미터 법칙 위반 여부는 ctxt, Options, ScratchDir이 객체인지 자료구조인지에 따라 다르다.
```
// 함수 하나가 아는 지식이 많음
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath(); 
```
  ⬇
```
// 1) 객체인 경우
// 1-1) 행 단위로 끊어서 작성
Options opts = ctxt.getOptions();
File scratchDir = opts.getScratchDir();
final String outputDir = scratchDir.getAbsolutePath();

// 1-2) `ctxt`가 정보를 얻는 것이 아닌 행위를 하도록 함 (구조체 감추기)
BufferedOutputStream bos = ctxt.createSctatchFileStream(classFileName);
```
```
// 2) 자료구조인 경우
final String outputDir = ctxt.options.scratchDir.absolutePath;
```
- 자료 구조는 무조건 함수 없이 공개 변수만 포함하고, 객체는 비공개 변수와 공개 함수를 포함하는 것이 좋다.
  (하지만 bean과 같이 예외적으로 단순한 자료 구조에도 Getter/Setter를 정의하라 요구하는 프레임워크와 표준은 있다.)

자료 전달 객체 (p.126)
- 자료 구조체의 전형적인 형태는 공개 변수만 있고 함수가 없는 클래스
- 자료 구조체를 때로는 자료 전달 객체(DTO, Data Transfer Object)라 한다.
- 활성 레코드 는 DTO의 특수한 형태로, save/find 같은 탐색 함수도 제공하며, DB 의 테이블이나 다른 소스에서 자료를 직접 변환한 결과이다.
- 활성 레코드는 객체가 아닌 자료구조로 취급해야 한다. 비즈니스 로직을 담으면서 내부 자료를 숨기는 객체는 따로 생성한다.
  (내부 자료는 활성 레코드의 인스턴스일 가능성이 높음)

결론 (p.128)
- 객체는 동작을 공개하고 자료를 숨기며, 자료구조는 동작 없이 자료를 노출한다.
- 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 더 적합하고,
  새로운 동작을 추가하는 유연성이 필요하다면 자료 구조와 절차적인 코드가 더 적합하다.

기차 충돌 관련 내용을 읽을 때 '이벤트 체이닝이나 함수형 프로그래밍과 같은 코딩 방식은 그러면 어떻게 대체해야 하지?' 라는 생각이 들었는데, 객체가 정보를 얻는 것이 아닌 행위를 하도록 해야 한다는 내용에서 명쾌한 해답을 얻은 듯한 느낌이었다.
또한, 이번 챕터를 읽으며 전반적으로 그동안 "객체"와 "자료구조"를 혼합한 일명 "잡종 구조"를 통해 구현된 코드를 많이 봐왔다는 것을 느꼈고, 나 또한 그랬던 것 같아 반성하였다. 객체지향의 편견에 사로잡히지 않되 규칙을 준수하는 코드를 작성할 수 있도록 노력해야겠다.

VISITOR 패턴 : 방문자와 방문 공간을 분리하여, 방문 공간이 방문자를 맞이할 때, 이후 행동을 방문자에게 위임하는 패턴
- 알고리즘을 객체 구조에서 분리시키는 디자인 패턴
- 행동의 대상이 되는 객체가 행동을 일으키는 객체를 파라미터로 받음

휴리스틱 : 불충분한 시간이나 정보로 인하여 합리적인 판단을 할 수 없거나, 체계적이면서 합리적인 판단이 굳이 필요하지 않은 상황에서 사람들이 빠르게 사용할 수 있게 보다 용이하게 구성된 간편추론의 방법

디미터 법칙 : 다른 객체가 어떠한 자료를 갖고 있는지 자세한 속사정을 몰라야 한다는 법칙
- 객체에게 자료를 숨기는 대신 함수를 공개
- 여러 개의 도트(.)를 사용하지 말라는 법칙으로도 알려짐
- 이를 준수함으로써 캡슐화를 높여 객체의 자율성과 응집도를 높일 수 있음