객체지향 설계의 목표는 적절한 책임을 수행하는 객체들의 협력을 기반으로 결합도가 낮고 재사용 가능한 코드 구조를 창조하는 것이다.

일관성있고 유사한 협력 패턴을 사용해야 코드가 늘어나도 인지부하가 줄어든다.

우리가 만들었던 핸드폰 요금제 코드 요구사항을 변경해보면서 변화를 어떻게 시킬 수 있는지 알아보자.

• 코드 제시했음

p.487

근데.. 일관성 없는 코드 구현 방식이 문제라고 했는데 사실상 요금제 문제는 각각이 다른 구현 방식을 택해야하는 문제아닌가? 여기서 일관성을 억지로 넣는게 더 이상해질 것 같은데..

• 변하는 부분과 변하지 않는 부분을 구분하긴 했는데.. 이게 다른 요구사항이 추가됐을 때도 이게 통할까? 이게 통하지 않는 요구사항이 들어올 경우 도메인 로직 구조를 전체적으로 뜯어고쳐야하는 건 아닐까?
• 애초에 좀 더 자유로운 구현 방식을 주고 틀을 만들지 않았다면 좀 더 나은 경우도 있지 않을까라는 생각이 들었음.

훌륭한 구조 설계를 위해 따라야하는 기본 원칙 (디자인 패턴도 대부분 이를 따른다.)

1. 변하는 개념을 변하지 않는 개념으로부터 분리하라.
2. 변하는 개념을 캡슐화하라.

조건 로직을 객체 사이의 이동으로 변경하기 위해서는 커다른 클래스를 더 작은 클래스로 분리해야한다.

그렇다면 어떤 기준으로 클래스를 분리할까?

• 변경의 이유 → 클래스는 단 하나의 이유에 의해서 변경 되어야하고
• 변경의 주기 → 클래스 안의 모든 코드는 함께 변경되어야 한다.