[CleanCode]객체와 자료구조 2

 

디미터 법칙
Law of Demeter
: 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다.

• 객체는 자료를 숨기고 함수를 공개한다.
• 즉, 객체는 조회함수로 내부 구조를 공개하면 안된다는 의미다.
• 대표적인 휴리스틱이다.

휴리스틱  Heuristic
완벽하진 않지만, 일반법으로 좋은/간단한 해결법을 말한다.

• 자세한 예시로
  클래스 C의 메서드 f는 다음과 같은 객체의 메서드만 호출해야 한다.
  • 클래스 C
  • f 가 생성한 객체
  • f 인수로 넘어온 객체
  • C 인스턴스 변수에 저장된 객체
• 하지만 위 객체에서 허용된 메서드가 반환하는 객체의 메서드는 호출하면 안된다.

복잡한 듯이 보이지만 디미터 법칙을 위반하는 사례만 피하면 된다.
클래스 A→B에서 조회를 했다면 B에 있는 자료만 가져와야지
A→B→C조회를 하면 안된다는 거다.

디미터 법칙 위반 사례

한마디로 코드가 꼬인 상태.

기차 충돌 Train wreck

이렇게 여러 객체가 한 줄로 이어진 상태를 기차 충돌로 부른다. 당연히 안 좋은 코드이다.

---

위 예제가 만약 자료 구조라서 이런 식으로 공개 변수 public을 사용한다면

다음과 같이 구현했다면 디미터 법칙을 따를 필요가 없어진다.

이 사례는 자료구조는 무조건 함수없이 공개 변수만 포함하기때문이고
객체에서는 아니다.

---

잡종구조
위와 같이 디미터 법칙을 위반하면 코드가 꼬이는 혼란이 생기는데
개발자는 이 코드를 활용하기 위해 절반은 객체, 절반은 자료 구조인 잡종구조를 만들게 된다.
이렇게 되면 이전 글에서 설명했던 바와 같이 새로운 함수/자료구조 모두 추가하기 어려운 상황이 된다.

---

그래서 정답은

• 결국 가져오려는 것은 File Path이다.
• 이를 가져오기 위한 함수를 구현하면 내부구조를 들어내지 않을 수 있다.
• 함수를 새로 만들면 되는 것이지 이것 저것 끌어다 쓰는 순간 코드가 꼬이게 되는 것 같다.

---

자료 전달 객체
자료구조체의 전형적인 형태는 공개 변수만 있고 함수가 없는 클래스이다.
DTO(Data Transfer Object)라고도 한다.
Socket이나 DB에 저장된 정보를 코드에서 사용할 객체로 변환하는 과정에서 첫번째로 사용된다.
굉장히 유용하게 사용된다.

좀 더 일반적인 형태로는 빈Bean 구조이다.
(이전에 많이 사용되었는데, 아직도 현장에서 리팩토링할 때 AS-IS 코드에서 많이 보입니다)
일종의 사이버 캡슐화로 별다른 이익은 제공하지 않는다.

DTO 예시

활성레코드
DTO의 특수한 형태.
비즈니스 규칙 메서드를 추가해 사용하는 경우가 많은데
이런 경우 잡종구조가 나오기 때문에 추천하지 않는다.