Intention Revealing Interface

클라이언트 개발자가 객체를 효과적으로 사용하는 데 알아야 할 정보를 인터페이스로부터 얻지 못한다면 세부적인 측면을 이해하고자 객체 내부를 깊이 파고들 수 밖에 없다. 이 경우에는 캡슐화를 통해 얻을 수 있는 대부분의 가치를 잃어버리고 만다.

개발자가 컴포넌트를 사용하기 위해 컴포넌트의 구현 세부사항을 고려해야 한다면 캡슐화의 가치는 사라진다. 원래의 개발자가 아닌 다른 개발자가 구현 내용을 토대로 객체나 연산의 목적을 추측해야 한다면 새로운 개발자는 우연에 맡긴 채 연산이나 클래스의 목적을 짐작할 가능성이 있다. 추측한 바가 원래의 취지에 어긋난다면 당장은 코드가 정상적으로 동작했다고 하더라도 설계의 개념적 기반은 무너지고 두 개발자는 서로 의도가 어긋난 상태로 일하게 된다.

도메인 내에 존재하는 개념을 클래스나 메서드의 형태로 명확하게 모델링해서 가치를 얻으려면 해당 도메인 개념을 반영하도록 클래스와 메서드의 이름을 지어야 한다. 클래스와 메서드의 이름은 개발자 간의 의사소통을 개선하고 시스템 추상화를 향상시킬 아주 좋은 기회다.

수행 방법에 관해서는 언급하지 말고 결과와 목적만을 표현하도록 클래스와 연산의 이름을 부여하라. 이렇게 하면 클라이언트 개발자가 내부를 이해해야 할 필요성이 줄어든다. 이름은 팀원들이 그 의미를 쉽게 추측할 수 있게 UBIQUITOUS LANGUAGE 에 포함된 용어를 따라야 한다. 클라이언트 개발자의 관점에서 생각하기 위해 클래스와 연산을 추가하기 전에 행위에 대한 테스트를 먼저 작성하라.

References

  • 도메인 주도 설계 / Eric Evans 저 / 위키북스