[오브젝트] 메세지와 인터페이스

woohobi·2022년 1월 17일
0

Book Review

목록 보기
4/5

메세지와 인터페이스

앞선 장에서 역할과 객체에 대해서 자세하게 살펴보았다. 메세지를 호출할때, 적합한 역할을 먼저 찾고, 역할에 해당하는 객체를 찾았다. 이와 비슷하게 책임에 대해서도 메세지 인터페이스( 오퍼레이션 )와 런타임에 결정되는 메서드로 나눌 수 있다. 추상화 된 관점에서 메세지를 선택하고, 실제 런타임 환경에서 메서드가 결정된다.

좋은 설계에 도달하기 위해서 적절한 추상화가 필요하지만 최소화해서 꼭 필요한 인터페이스만을 포함해야 한다. 좋은 인터페이스의 특징은 다음과 같다.

디미터 법칙

: 오직 인접한 이웃하고만 말하라

이는 메세지 수신자와 송신자를 느슨한 결합하게 만들고 적절한 객체에 책임을 할당한다. 디미터 법칙을 지키지 않으면, 내부의 구현 내용을 외부에 노출 시킬 위험이 있고, 이는 유지보수를 어렵게 만드는 원인이다.

묻지 말고 시켜라

해당하는 상태를 가진 객체를 외부에서 변경하지 말고, 책임을 할당하는 것이 더 좋은 설계이다. 높은 응집도를 만든 객체를 만들 수 있다. 이 때, 객체는 어떻게 하는지 보다 무엇을 하는지에 초점을 맞추어야 한다.

/.as is
public boolean isSatisfiedBySequence(Screening screening)

//to be
public boolean isSatisfied(Screening screening)

as is 와 같이 메소드를 만들면 외부에 구현 사항을 노출할 뿐 아니라, sequence에 변경에 따라 메소드도 함께 변경되어야만 한다. 따라서 to be와 같은 메소드 작성이 더욱 효과적이다.

명령, 쿼리 분리 원칙

메소드는 사이드 이펙트를 발생시키고 값을 반환하지 않는 명령과 사이드 이펙트를 발생시키지 않고 값을 리턴하는 쿼리로 나눌 수 있다.

이 원칙은 단일 책임 원칙과도 비슷하게 느꼈다. 하나의 메소드는 단 하나의 행동만 하여야 한다. 단일 책임만을 수행함으로써, 미연에 발생할 오류를 방지하고 재사용성을 높일 수 있다.
사이드 이펙트를 발생시키지 않는 쿼리를 확장해서 객체지향 프로그래밍에 함수형 프로그래밍 패러다임을 접목시킬 수 있다.

profile
CDD - Coffee Driven Development

0개의 댓글