[객체지향] 7. 함께 모으기

서문

객제지향 설계안에 세 가지 상호 연관된 관점이 있다. 이 세 가지 관점을 개념 관점, 명세 관점, 구현 관점이라고 부른다

 

개념 관점 에서는 설계는 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현한다. 이 관점은 사용자가 도메인을 바라보는 관점을 반영한다. 따라서 실제 도메인의 규칙과 제약을 최대한 유사하게 반영하는 것이 핵심이다.

 

명세 관점에서는 소프트웨어로 초점이 옮겨진다. 도메인이 아닌 실제 객체들의 책임에 초점을 맞추게 된다. 이 관점에서 프로그래머는 객체가 협력을 위해 무엇을 할 수 있는지에 초점을 맞춘다.

 

구현 관점은 프로그래머에게 익숙한 실제 코드와 연관돼 있다. 객체들이 책임을 수행하는 데 필요한 동작하는 코드를 작성하는 것에 초점을 맞춘다.

 

이 세가지 관점은 동일한 클래스를 세 가지 다른 방향에서 바라보는 것을 의미한다. 클래스는 도메인 관점을 반영하고, 클래스의 공용 인터페이스는 명세 관점을 반영하며, 클래스의 속성과 메서드는 구현 관점을 반영한다. 클래스는 세 가지 관점을 모두 수용할 수 있도록 깔끔하게 분리해야 한다.

 

커피 전문점 도메인

커피 전문점을 예시로 현실에서 커피를 주문하는 과정을 객체들의 협력 관계로 구현하는 예시를 설명한다. 이 부분은 책을 직접 읽으며 살펴보는 것을 추천한다. 중요한 점 몇가지만 기록하겠다.

• 훌륭한 협력을 설계하기 위해 메시지를 선택하고 메시지를 수신할 객체를 선택해야 함을 떠올리자.
• 의사소통이라는 목적에 부합한다면 용도에 맞게 얼마든지 UML을 수정하고 뒤틀어라. UML을 의사소통을 위한 표기법이지 꼭 지켜야 하는 법칙이 아니다.

코드의 세 가지 관점

앞의 예시는 개념, 명세, 구현 관점에서 각기 다른 사항들을 설명해준다.

 

개념 관점에서 코드를 보면 클래스들이 커피 전문점 도메인을 구성하는 중요한 개념과 관계를 반영함을 알 수 있다. 소프트웨어 클래스가 도메인 개념의 특성을 최대한 수용하면 변경을 관리하기 쉽고 유지보수성을 향상시킬 수 있다. 소프트웨어 클래스와 도메인 클래스 사이의 간격이 좁으면 좁을수록 긴으 변경을 위한 코드의 양도 줄어든다.

 

명세 관점은 클래스의 인터페이스를 바라본다. 클래스의 public 메소드는 다른 클래스가 협력할 수 있는 공용 인터페이스를 드러낸다. 인터페이스를 수정하면 해당 객체와 협력하는 모든 객체에게 영향을 미칠 수밖에 없다. 따라서 수정하기 어렵다는 사실을명심하고 구현과 관련된 세부 사항이 드러나지 않게 만들자.

 

구현 관점은 클래스의 내부 구현을 바라본다. 클래스의 메소드와 속성을 구현에 속하며 인터페이스의 일부가 아니다. 따라서 메소드의 구현과 속성의 변경이 외부의 객체에게 영향을 미쳐서는 안된다. 철저하게 클래스 내부로 캡슐화하자.

 

훌륭한 프로그래머는 하나의 클래스 안에 세 가지 관점을 모두 포함하면서도 각 관점에 대응되는 요소를 명확하게 드러낼 수 있다.

 

인터페이스와 구현을 분리하라.

여러번 강조하는 사실이다.

명세 관점과 구현 관점이 뒤섞여 머릿속을 어지럽히지 못하게 하라. 명세 관점이 설계를 주도하게 하면 설계의 품질이 향상될 수 있다. 명세 관점은 클래스의 안정적인 측면을 드러내야 하고, 구현 관점은 클래스의 불안정한 측면을 드러내야 한다. 인터페이스가 구현 세부 사항을 노출하면 안 된다.

---

느낀점

책의 끝까지 인터페이스와 구현의 분리를 강조한 게 인상깊다. 매우매우 중요한 개념이라고 느꼈다.

도메인 모델을 기반으로 클래스를 설계하는 게 유지보수에 있어 중요함을 느꼈다.

 

책을 읽어서 당장 내 실력이 크게 늘어나진 않았겠지만, 객체지향을 바라보는 시각이 더 넓어지고 좋은 코드를 만들 수 있는 밑거름이 되리라 믿는다.