느낀점 먼저

추상화에 대한 이야기, 그리고 객체지향 코드와 절차지향 코드의 장단점과 어떤 상황에서 적합한가에 대한 내용이었다.
디미터 법칙에 대한 부분에서는 '기차 충돌 코드'라는 이야기가 나왔다. 메소드의 리턴값을 이용해서 줄줄이 다른 메소드의 파라미터로 호출했던 나의 지난 코드들이..스쳐지나갔다...
기차 충돌 코드라도 리턴값이 객체인지 자료구조인지에 따라서 위반 여부도 달라지는데, 다행히 최근 코딩 스타일은 디미터 법칙을 위반했던 적이 거의 없던 것 같다.

그동안 그냥 느낌적인 느낌으로 왠지 이 방법이 맞는거 같아...하며 작성했던 코드들이 왜 더 깔끔해보이고 그래야 할 것만 같았는지(반쪽짜리 객체지향 지식 때문으로 추정) 조금은 이해가 갔다.
이유 있는 코드, 근거 있고 기준이 있는 코드를 작성할 수 있도록 도움이 될 것 같은 챕터였다.

---

내용 요약

개발자가 get, set 함수를 public하게 선언해서 private 변수를 외부에 노출시키는 이유는 무엇일까?

자료 추상화

변수를 private하게 선언한다 하더라도 변수에 접근할 수 있는 get, set 함수를 제공한다면 구현을 외부로 노출하는 셈이다.
변수에 접근하는 함수 계층을 넣는다고 구현이 감추어지는 것이 아니라, 추상화가 필요하다.
즉, 추상 인터페이스를 제공해 구현을 모르고도 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스인 것이다.

자료/객체 비대칭

절차지향 코드와 객체 지향 코드는 서로 상반되는 점이 있다.
절차지향 코드는 자료구조 변경 없이 함수를 추가하기 용이하다. 반면, 객체지향 코드는 기존 함수의 변경 없이 새 클래스를 추가하기 쉽다.
또한, 절차지향 코드는 새로운 자료구조를 추가하려면 모든 함수를 고쳐야한다. 반면, 객체지향 코드는 새로운 함수를 추가하려면 클래스의 수정이 불가피하다.

디미터 법칙

디미터법칙이란 모듈은 자신이 조작하는 객체의 내부를 몰라야 한다는 법칙이다.
함수의 반환값을 이용해서 호출한 함수의 반환값을 이용해서 함수를 호출......과 같은 코드를 기차 충돌이라고 부르는데, 일반적으로 조작하다 여겨지는 방식이므로 피하는 편이 좋다.
이런 경우에서 디미터 법칙을 위반하는지 여부는 함수의 반환값이 객체인지 자료구조인지에 달렸다. 객체라면 내부 구조를 숨겨야하므로 위반이고, 자료구조라면 내부 구조를 노출하므로 디미터 법칙이 적용되지 않는다.
자료구조는 함수 없이 public 변수만 포함하고, 객체는 private 변수와 public 함수를 포함한다면 혼란을 줄일 수 있을 것이다.

결론

객체는 동작을 공개하고 자료를 숨긴다. 그래서 새 객체 타입을 추가하기는 쉽지만 새 동작을 추가하기는 어렵다.
자료구조는 별다른 동작 없이 자료를 노출하기 때문에 새 동작을 추가하기는 쉽지만 기존 함수에 새 자료구조를 추가하기 어렵다.

어떤 시스템을 구현할 때, 새 자료 타입을 추가할 가능성이 높다면 객체가 더 적합하고, 새로운 동작을 추가할 가능성이 높다면 자료구조와 절차지향적 코드가 더 적합하다.