클린코드 6장 : 객체와 자료 구조

0. 시작하는 글

: 변수를 비공개로 정의하는 것은 남들이 변수에 의존하지 않게 만들고 싶어서이다. 왜 많은 프로그래머가 set, get 함수를 공개 해 비공개 변수를 외부에 노출 시킬까?

1. 자료 추상화

: 인터페이스는 자료구조를 명백하게 표현한다. 아래 두번째 예는 자료 구조 이상을 표현한다.

ex1 ) 구체적인 Point 클래스

public class Point{

public double x;

public double y;

}

-> 직교 좌표계로 개별적으로 좌표값을 읽고 설정하게 강제함.

ex2) 추상적인 Point 클래스

public interface Point{

double getX();

double getY();

void setCartesian(double x, double y);

double getR();

}

-> 좌표를 읽을 때 각 값을 개별적으로 읽어야 하고, 좌표 설정시 두 값을 한번에 설정 해야 함. private으로 변수를 선언하더라도 set, get함수를 통해 구현이 외부로 노출됨

# set, get함수 : 프로그래머가 일반적으로 객체를 저장(설정), 조회(불러오기)할 때 사용하는 함수

변수 사이에 함수라는 계층을 넣어도 구현이 저절로 감춰지지 않음 -> 구현을 감추려면 추상화가 필요

=> 결론 : ex1보다 ex2처럼 자료를 세세히 공개하기 보다 추상적인 개념으로 표현하는게 좋음 

    # 아무 생각없이 설정/조회(set/get)함수를 추가하지는 말자

2. 자료 / 객체 비대칭

분류	장점	단점
절차적 코드	기존 자료구조를 변경하지 않으며 새함수 추가 쉬움	새로운 자료구조 추가가 어려움
객체 지향 코드	기존 함수를 변경하지 않으면서 새 클래스 추가 쉬움	새로운 함수 추가가 어려움(추가하려면 모든 클래스를 고쳐야 함)

3. 더미터 법칙

: 휴리스틱(Heuristic)으로 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙

-> 객체는 자료를 숨기고 함수를 공개

1) 기차 충돌

: 코드를 한줄에 다쓰면 여러 객차가 한줄로 이어진 기차처럼 보이기 때문에 기차충돌이라고 함

ex)

final string outputVal = felix.getOptions().getRelativePath().getColor();

---->

Option option = felix.getOptions();

Path path = felix.getRelativePath();

Color color = felix.getColor();

2) 잡종구조

: 위 같은 혼란으로 절반은 객체, 절반은 자료 구조인 잡종 구조(정의가 뒤섞임)가 나옴

-> 이런 잡종 구조는 새로운 함수, 새로운 자료구조 추가가 어려움

3) 구조체 감추기

ex) 임시디렉터리의 절대 경로는 어떻게 얻어야 할까?

-> BufferedOputputStrem bos = ctxt.createScratchFileStream(classFileName);

4. 자료 전달 객체

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

-> DTO는 유용한 구조체, 데이터베이스와 통신하거나 소켓에서 받은 메시지 구문 분석할 때 유용?

: 좀 더 일반적인 형태는 빈(bean) 구조(빈구조는 비공개(private) 변수를 get/set 함수로 조작)

1) 활성 레코드

: 활성 레코드는 DTO의 특수한 형태임

- 활성레코드는 데이터베이스 테이블이나 다른 소스에서 자료를 직접 변환한 결과임

-> 활성 레코드는 자료구조로 취급하고 비즈니스 규칙을 담으며 내부 자료를 숨기는 객체는 따로 생성해야 함

5. 결론

: 객체는 동작을 공개하고 자료를 숨김

: 기존 동작을 변경하지 않으면서 새 객체 타입 추가는 쉽지만 새 동작 추가는 어려움

어떤 시스템 구현시 새로운 자료 타입 추가하는 유연성이 필요하면 -> 객체가 더 적합

새로운 동작을 추가하는 유연성이 필요하면 -> 자료구조와 절차적인 코드가 더 적합