10/10 TIL | 데메테르의 법칙(Law of Demeter)

8주차 주간 학습의 첫날! 이번 주 1주 1개발서적 프로젝트로 『개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴』을 읽기 시작했다. 읽었던 파트 중에 캡슐화 파트에서 캡슐화를 위한 규칙으로 데메테르의 법칙(Law of Demeter)이 소개되었다. 사실 이 법칙을 처음 보자마자 『젊은 베르테르의 슬픔』이 떠올랐는데 제나님도 나랑 똑같은 생각을 했다길래 너무 웃겼다.. 어쩔 수 없는 진성 문과생들..

---

데메테르의 법칙(또는 디미터의 법칙)은 "Tell, Dont' Ask"의 규칙을 따를 수 있도록 만들어 주는 규칙인데, 이때 "Tell, Don't Ask"는 데이터를 물어보지 않고, 기능을 실행해 달라고 말하라는 규칙이다. 이 두 가지 규칙은 객체 지향 언어의 특징 중 하나인 캡슐화를 위해서 필요한 규칙이다.

캡슐화(encapsulation)란 객체가 내부적으로 기능을 어떻게 구현하는지를 감추는 것을 말하는데 이를 통해 내부의 기능 구현이 변경되더라도 그 기능을 사용하는 코드는 영향을 받지 않도록 만들어준다. 즉, 내부 구현 변경의 유연함을 주는 기법이 바로 캡슐화라고 할 수 있다.

컴퓨터 과학자 칼 리버헤르(Karl Lieberherr)와 그의 동료들은 데메테르(Demeter)라는 프로젝트 산하에서 훌륭한 객체 설계 원칙에 대해 연구하던 도중 그들은 객체 구조의 변화와 불안정이 자주 발생되는 것을 보았고 객체 연결에 관한 정보를 지닌 코드는 불안정하다는 사실을 접하면서 데메테르 법칙(Don't Talk to Strangers)을 만들었다.

데미테르의 법칙은 다음과 같이 간단한 규칙으로 구성된다.
- 메서드에서 생성한 객체의 메서드만 호출
- 파라미터로 받은 객체의 메서드만 호출
- 필드로 참조하는 객체의 메서드만 호출

데미테르의 법칙을 따르면, 데이터 중심이 아닌 기능 중심으로 코드를 작성할 수 있기에 기능 구현의 캡슐화를 향상시킬 수 있다.

// AS-IS
member.getDate().getTime()

// TO-BE
member.someMethod()

예를 들어 회원 만료 여부를 확인하는 코드는 member.getDate().getTime() 이런 식으로 getter 함수로 정보를 불러올 수 있다. 하지만 이 경우 데메테르의 법칙에 위배된다. 앞서 설명했던 규칙 중 파라미터로 전달받은 객체는 객체의 메서드만 호출하여야 하는데, 이 경우 파라미터로 전달받은 member의 getDate() 메서드만을 호출한 뒤에, 다시 getDate()가 리턴한 Date 객체의 getTime() 메서드를 호출하였기 때문이다. 그렇기에 someMethod()로 한번의 member 객체 메서드 호출로 변경되어야 한다.

그렇다면 데메테르의 법칙이 잘 지켜지지 않을 때를 어떻게 감지할 수 있을까? 이는 연속적으로 get 메서드가 호출되고 있다거나 임시 변수의 get 호출이 많다면 데메테르의 법칙이 잘 지켜지지 않는다고 판단할 수 있다. 위에서 설명했던 코드와 같은 케이스를 연속된 get 메서드 호출이고, 두 번째 임시 변수에 할당된 객체의 get을 호출하는 코드가 많은 경우는 아래와 같다.

A a = someObject.getA();
B b = a.getB();
value = b.getValue();

어떤 객체에서 a라는 객체를 가지고 오고, 그렇게 가져온 a에서 b를 가져오고, b에서 value를 또 얻어오는 방식이다. 이 또한 데메테르의 법칙이 잘 지켜지지 않았다고 판단할 수 있다.

---

3주차에 객체 지향 사실과 오해를 읽으면서 객체 지향의 전체적인 개념을 추상적으로 한번 잡고, 이번 주에 읽는 책의 코드 예제를 통해서 객체 지향의 자세한 개념들과 패턴들을 확인할 수 있어서 더 와닿고 재밌는 거 같다. 더 열심히 읽어서 객체 지향을 정복해보자! 💪

내용과 상관없는 사진이지만 항상 저의 TIL을 보러 와 주신 분들 감사합니다. 열심히 공부하고 기록할게요. 그럼 행복한 하루 되세요 *^^*
(사실 그냥 TIL에 딱 알맞은 썸네일 사진을 찾지 못함ㅎ)