객체 지향 설계 속 세 가지 상호 연관된 관점
1. 개념관점
✔️ 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현하는 설계이다.
도메인 : 사람들이 관심을 가지고 있는 특정 분야나 주제
→ 소프트웨어가 도메인 속 문제를 해결하기 위해 개발되기 때문에 이 관점은 사용자가 도메인을 바라보는 관점을 반영한다.
→ 실제 도메인의 규칙과 제약을 최대한 유사하게 반영하는 것이 핵심
2. 명세 관점
사용자의 영역인 도메인을 벗어나 개발자가 주목하는 객체들의 책임에 초점이 맞춰진다. 즉, 객체들이 협력을 위해 어떤 일을 할 수 있는가에 초점을 맞춘다. 많은 개발자들이 객체의 인터페이스와 구현을 클래스 안으로 넣는데
중요한 것은 인터페이스와 구현을 분리하는 것이다.
3. 구현 관점
구현 관점의 초점은 객체들이 책임을 수행하는 데 필요한 코드를 작성하는 것이다
개발자는 객체의 책임을 '어떻게' 수행할 시킬 것인가에 초점을 맞추며 인터페이스를 구현하는 데 필요한 속성과 메서드를 클래스에 추가
💡개념 → 명세 → 구현 관점의 순서대로 소프트웨어를 개발한다는 것이 아니라, 동일한 클래스를 세 가지 관섬에서 바라보는 것을 의미
- 개념 관점 : 클래스가 은유하는 개념
- 명세 관점 : 공용 인터페이스
- 구현 관점 : 클래스의 속성과 메서드
설계하고 구현하기
협력 찾기
✔️훌륭한 객체를 만드는 것이 아닌, 훌륭한 협력을 설계하는 것이 객체지향의 첫 목표
✔️ 객체가 메시지를 선택하는 것이 아니라, 메시지가 객체를 선택하게 해야한다.
→ 메시지를 먼저 선택하고 그 후에 메시지를 수신하기에 적절한 객체를 선택해야 한다는 뜻
인터페이스 정리하기
✔️ 객체가 수신한 메시지가 객체의 인터페이스를 결정한다.
→ 메시지가 객체를 선택하면 선택된 객체는 메시지를 자신의 인터페이스로 받아들인다.
✔️ 객체가 어떤 메시지를 수신할 수 있다는 것은 그 객체의 인터페이스안에 메시지에 해당하는 오퍼레이션이 존재한다는 것
구현하기
✔️ 클래스의 인터페이스를 식별했으므로 오퍼레이션을 수행하는 방법을 메서드로 구현
❗️ 코드를 통한 피드백 없이는 깔끔한 설계를 얻을 수 없다
훌륭한 협력을 위해서 설계는 물론 너무나도 중요하지만, 객체들이 협력을 수행하도록 하기 위해선 구현을 해야한다. 따라서 설계에 너무 오랜 시간을 쏟지 말고, 최대한 빨리 코드를 구현해서 설계에 이상이 없는지, 설계가 구현 가능한지를 판단해야 한다.
코드와 세 가지 관점
코드는 세가지 관점을 모두 제공해야 한다
✔️ 개념관점 - 클래스는 도메인을 구성하는 중요한 개념과 관계를 반영한다.
ex ) 현실 세계에서 커피를 제조하는 것은 바리스타이기 때문에, 커피 제조하는 과정을 변경해야한다면
바리스타 클래스 내부를 수정해야한다.
→ 소프트웨어의 클래스들과 도메인 사이의 차이가 적을 수록, 유지보수를 하기가 쉽다.
✔️ 명세관점 - 클래스의 인터페이스를 바라본다.
객체의 공용 인터페이스 외부에서 해당 객체에 접근할 수 있는 유일한 경로이다.
❗️인터페이스를 수정하면 해당 객체와 협력하는 모든 객체에 영향을 미칠 수 밖에 없다.
→ 따라서, 객체의 인터페이스는 수정하기 어렵다. 변화에 안정적인 인터페이스를 만들기 위해서는 인터페이스를 통해 구현과 관련된 사항들이 드러나지 않게 해야한다.
✔️구현관점 - 클래스의 내부 구현을 바라본다.
❗️클래스의 메서드와 속성은 구현의 부분이지, 인터페이스의 일부가 아니다.
→ 따라서, 메서드의 구현과 속성을 수정했을 때, 외부의 객체에 영향을 미치면 안된다 ( 캡슐화 )
도메인 관점을 참조하는 이유
메시지를 수신할 객체를 정하는 방법
→ 도메인 개념 중에서 가장 적절한 것을 선택하는 것. 이는 코드의 구조와 의미를 도메인을 기반으로 이해할 수 있다는 이점을 준다. 또한, 이런 방법을 따르면, 변경에 쉽게 대응할 수 있는 장점이 있다.
인터페이스와 구현을 분리하라
객체의 안정적인 부분인 인터페이스와 불안정한 부분인 구현을 분리해야한다.
→ 구현 부분이 외부로 노출이 된다면, 구현 부분의 아주 작은 변경에도 협력 구조는 쉽게 흔들릴 수 있다.
0개의 댓글
