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

6장. 객체와 자료 구조

🧩 자료를 감춰야 하는 이유

변수를 private으로 감추는 이유는 단순하다.
다른 코드가 변수에 직접 의존하지 않게 하려는 것.
그래야 나중에 내부 구현을 마음대로 바꾸더라도 문제가 생기지 않는다.

그런데 많은 프로그래머들이 get, set 함수만 덜컥 만들어서 결국 변수에 직접 접근하게 만든다.
이건 사실상 캡슐화를 깨는 것과 다름없다.

단순히 조회/설정 함수를 붙인다고 클래스가 되는 게 아니다.
진짜 캡슐화는 “구현이 어떻게 되어 있는지 외부에서 알 수 없게 만드는 것”이다.

---

🧭 자료 추상화란?

예시 1: 나쁜 추상화

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

→ 내부 구현이 그대로 드러난 단순한 자료 구조일 뿐이다.

 

예시 2: 좋은 추상화

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

→ 이 코드만 봐선 직교좌표계를 쓰는지, 극좌표계를 쓰는지 전혀 알 수 없다.

구현 방식이 완전히 감춰져 있고, 인터페이스만으로도 의도를 충분히 표현하고 있다.
이런 방식이 진짜 자료 추상화에 가까운 설계다.

📐 객체 vs 자료 구조: 서로 반대되는 특성

 

객체(Object)	자료 구조(Data Structure)
자료를 감추고 함수만 공개함	자료를 공개하고 함수는 거의 없음
새 자료 타입 추가는 쉬움	새 동작(함수) 추가는 쉬움
새 동작 추가는 어려움	새 자료 타입 추가는 어려움

→ 둘 중 하나가 더 좋다고 말할 수 없다. 문제에 따라 맞는 구조를 고르는 게 중요하다.

💥 기차 충돌과 디미터 법칙

아래 코드는 보기엔 간단하지만 디미터 법칙을 위반하고 있다.

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

이렇게 되면 ctxt가 내부적으로 무엇을 갖고 있는지 외부 코드가 너무 많이 알아야 한다.

→ 개선된 방법:

BufferedOutputStream bos = ctxt.createScratchFileStream(classFileName);

무엇을 하라고 시켜야지, 내부 구조를 꺼내서 조작하지 말자.

🧱 잡종 구조는 피하자

객체와 자료 구조의 특성을 어설프게 섞은 클래스는 주의해야 한다.
예를 들어 get/set 함수도 있고, 일부 비즈니스 로직까지 들어 있는 클래스는
객체도 자료 구조도 아닌, 양쪽의 단점만 가져온 잡종 구조가 된다.

그래서 애매하게 섞기보단 확실하게 나누는 게 낫다.
자료 구조는 자료 구조답게, 객체는 객체답게!

 

📦 DTO와 활성 레코드

• DTO (Data Transfer Object)
  단순히 데이터를 담는 구조체.
  함수는 없거나, 최소한의 get/set만 존재한다.
  
  
• 활성 레코드 (Active Record)
  데이터를 담으면서 save(), find() 같은 DB 관련 동작도 포함하는 구조.
  → 그런데 여기에 비즈니스 로직까지 얹기 시작하면, 금세 잡종 구조가 되어버리니 주의해야 한다.
  그러니 핵심은 역할 분리! 데이터를 담는 구조는 정말 그 역할에만 집중하도록 설계하는 게 좋다.
  
  

---

✍️ 마무리하며

객체는 동작을 중심으로, 자료 구조는 데이터를 중심으로 설계한다.

• 새로운 타입을 자주 추가해야 하는 상황이라면 → 객체 지향 설계가 더 유리하고
• 새로운 기능이나 동작을 계속해서 추가해야 한다면 → 자료 구조 + 절차형 설계가 적합하다

중요한 건 무조건 “객체 지향!” 혹은 “캡슐화!”를 외치는 게 아니라,
지금 내가 어떤 문제를 풀고 있는지에 따라 가장 적절한 설계를 선택할 줄 아는 태도다.