※ 이글은 독자를 전혀 배려하지 않고 그냥 제가 정리하고 싶은 내용 정리하는 글입니다.
197p~215p
원칙의 함정
소프트웨어 설계에 절대적인 법칙이란 존재하지 않는다. 법칙에는 예외가 없지만 원칙에는 예외가 넘쳐난다. 잊지 말아야 하는 사실은 설계가 트레이드오프의 산물이라는 것이다. 설계가 적절하게 트레이드오프 할 수 있는 능력이 숙련자와 초보자를 구분하는 가장 중요한 기준이라고 할 수 있다.
디미터법칙은 하나의 도트(.)를 강제하는 규칙이 아니다
- 디미터 법칙은 결합도와 관련된 것이며, 이 결합도가 문제가 되는 것은 객체의 내부 구조가 외부로 노출되는 경우로 한정한다.
결합도와 응집도의 충돌
- 클래스는 하나의 변경 의도만을 가져야 한다.
- 디미터법칙과 묻지 말고 시켜라 원칙을 무작정 따르면 애플리케이션은 응집도가 낮은 객체로 넘쳐날 것이다.
- 가끔식은 묻는 것 외에는 다른 방법이 존재하지 않는 경우도 있다. 대상이 데이터나 자료구조인 경우.
소프트웨어 설계에 존재하는 몇 안되는 법칙 중 하나는 "경우에 따라 다르다"이다.
명령-쿼리 분리 원칙
루틴(routine): 어떤 절차를 묶어 호출 가능하도록 이름을 부여한 기능 모듈
프로시저(procedure): 정해진 절차에 따라 내부 상태를 변경하는 루틴의 한 종류. 함수와 프로시저를 명확하게 구분하는 경우, 부수효과를 발생시킬 수 있지만 값을 반환할 수 없다.
함수(function): 어떤 절차에 따라 필요한 값을 계산해서 반환하는 루틴. 함수와 프로시저를 명확하게 구분하는 경우, 값을 반환할 수 있지만 부수효과를 발생시킬 수 없다.
명령과 쿼리는 객체의 인터페이스 측면에서 프로시저와 함수를 부르는 또 다른 이름이다.
명령 -> 프로시저, 쿼리 -> 함수
명령-쿼리 분리 원칙의 요지는 오퍼레이션은 명령인 동시에 쿼리여서는 안된다는 것
- 객체의 상태를 변경하는 명령은 반환값을 가질 수 없다.
- 객체의 정보를 반환하는 쿼리는 상태를 변경할 수 없다.
- 명령-쿼리 분리 원칙에 따라 작성된 객체의 인터페이스를 명령-쿼리 인터페이스라고 부른다.
명령과 쿼리를 분리함으로써 코드는 예측 가능하고 이해하기 쉬우며 디버깅이 용이한 동시에 유지보수가 수월해질 것이다.
- 쿼리는 몇번이고 반복적으로 호출하더라도 상관이 없음. 순서도 자유롭게 변경할 수 있음
- 참조 투명성의 장점을 제한적이나마 누릴 수 있음
- 참조 투명성: 어떤 표현식 e가 있을 때, 모든 e를 e의 값으로 바꾸더라도 결과가 달라지지 않는 특성
