객체
- 동작을 공개하고 자료를 숨김
- 새로운 자료 타입을 추가하는 유연성이 필요할 때 적절
자료구조
- 자료를 공개함
- 새로운 동작을 추가하는 유연성이 필요할 때 적절
디미터의 법칙
모듈은 자신이 조작하는 객체의 내부를 몰라야 함.
기차 충돌
메소드를 기차처럼 나열하는 것을 지양하고 나눠서 선언하는 방식을 추천.
이 책의 '복간에 부쳐'에 나오듯이 최근에는 오히려 읽기 쉬운 코드를 위해 메소드를 나열 하는 방식을 더 자주 사용하는 것 같다.
덧붙여 나는 나눠서 선언되는 변수들이 일으킬 지도 모르는 side effect에 대한 걱정도 있어서 되도록이면 변수 선언을 최소화 하는 것을 선호한다.(나만 그런가?)
활성레코드
- 데이터베이스 테이블이나 다른 소스에서 자료를 직접 변환한 결과
- 활성 레코드는 자료 구조로 취급하며 비즈니스 규칙을 담으면서 내부 자료를 숨기는 객체는 따로 생성한다.
Nest.js 와 typeORM에 연결시켜 생각하니 흥미로운 부분이다. Nest.js에서는 Service 내부에 typeORM으로 생성된 Entity에 대한 Repository를 숨겨 놓고 비즈니스 로직을 구현하는데 그 구조가 여기서 말하는 것과 딱 맞다.
비즈니스 규칙을 담으면서 내부 자료는 숨기는 객체 = Service
내부 자료 = Entity의 Repository
내 생각
저자는 경우에 따라 적합성을 판단해 객체 혹은 자료구조의 형태를 만들되 '잡종구조'를 피하라고 말한다.
처음 Java를 시작했을 때만 해도 클래스에 getter,setter를 만드는 것은 너무나 당연한 일이었고 이러한 번거로움을 해결하기 위한 플러그인도 있었다.
최근에는 DTO를 사용하는 경우가 많아서 '자료구조'라는 형태에 대해 거부감이 없지만 (오히려 즐겨 쓰는 수준) 그 시절의 나였다면 많이 당황스러웠을 것 같은 내용이었다.
