[10분 테코톡] 쿠다의 우테코 프로그래밍 요구사항을 왜 지켜야 할까?

문자열과 숫자를 그대로 넘기는 대신 도메인 객체로 감싸면 생성 시점 검증, 타입 안전성, 관련 행동을 한곳에 둘 수 있다. 일급 컬렉션도 목록을 단순 노출하지 않고 합계나 검증 같은 책임을 내부에 모아 데이터가 아니라 의미와 역할로 협력하게 한다.

필드가 지나치게 많은 God Object는 서로 다른 변경 이유를 한 클래스에 모아 결합도와 수정 범위를 키운다. 엔티티와 인스턴스 변수 수를 제한하면 주소나 연락처 같은 개념을 별도 객체로 분리하게 되고, 상위 객체는 세부 데이터 대신 협력 구조를 관리한다.

getter로 상태를 꺼내 외부에서 판단하고 다시 넣는 대신 객체에 의도를 담은 메시지를 보내 스스로 처리하게 한다. 한 줄의 점 하나 규칙은 먼 객체의 내부 구조를 연쇄 탐색하지 않게 해, 가까운 협력자에게만 요청하고 캡슐화된 구조 변경의 영향을 줄인다.

여러 요구사항은 읽기 쉬운 코드, 의미 있는 객체, 작은 책임, 행동 중심 협력을 반복해서 연습시키는 객체지향 생활 체조에 뿌리를 둔다. 모든 규칙을 실무의 절대 정답으로 적용하기보다 제한 속에서 설계 근육을 기른 뒤 상황별 비용과 이점을 판단해야 한다.