글을 시작하기 전에
- 책 내용을 요약하였다 하지만 개인적인 주관이 엄청 많습니다. 독후감 정도로만 봐주시면 감사합니다.
- 4챕터부터 시작됩니다. 기존 챕터 요약은 이전 편을 참고해 주세요.
4. 역할, 책임, 협력
협력 : 시스템의 궁극적인 목표를 달성하기 위해 여러 객체들이 서로 힘을 합치는 행위
책임 : 각 객체들이 협력의 목표를 달성하기 위해 맡은 일, 일의 성격에 따라 하는 것과 아는 것으로 나누어진다.
역할 : 협력을(정확히는 협력에 참여하는 객체) 추상화해서 다양한 협력을 포괄적으로 표현할 수 있게 함. 역할은 책임의 집합임.
역할이 조금 애매하다고 느낄 수 있다. 예를 들면 커피숍에서 (손님 - 바리스타), (손님 - 실습생) 이라는 두 가지 협력을 커피만드는 사람이라는 역할을 도입해서 (손님 - 커피 만드는 사람)이라는 협력으로 추상화시킬 수 있다.
커피 만드는 사람(역할)은 바리스타(책임), 실습생(책임)을 포함한다.
객체 지향 설계 기법
-
책임 주도 설계
이 책 전반을 관통하는 내용이다. 후반부에도 계속 나온다. -
디자인 패턴
모범이 되는 설계, 내가 무언갈 설계할 때 참고할만한 구조라고 생각하자. -
테스트 주도 개발
테스트 주도 개발에서 테스트하는 대상은 구현이 아니다. 대신 나의 설계가 옳은지, 내 객체들이 적절하게 책임을 수행하는지, 협력이 잘 돌아가는지를 평가한다.
5. 책임과 메세지
책임 설정하기
- 객체에게 자율적인 책임을 부과해야 한다. 뭘 시킬지는 정해주나 어떻게 동작할지는 객체 스스로가 정하도록 하는게 좋다.
- 그렇다고 책임이 너무 모호해서는 안된다. 어느 정도의 추상화는 복잡도를 낮춰주는 효과를 주지만 너무 추상적이면 협력을 수행하는데 아무 쓸모가 없다.
메시지
책임을 가진 객체들이 협력하려면 의사소통을 해줘야 한다. 메시지는 객체 간에 의사소통을 할 수 있는 유일한 방법이다.
메시지 수신자.메시지 내용(메시지 인자들)
메시지 수신자 : 내가 책임을 수행하기 위해 필요한 협력자
메시지 내용 : 내가 협력자로부터 도움을 받아야 하는 행위
메시지 인자 : 협력자가 내가 원하는 행동을 하기 위해 필요한 정보
메서드
메시지 수신자는 다른 객체로 부터 메시지를 수신 받으면 해당 메시지를 수행한다. 이때 해당 메시지를 수행하는 부분을 메서드라고 한다.
객체 내에서 메시지는 '무엇을'에 관한 정보를 담고있고 메서드는 '어떻게'에 관한 정보를 담고있다. 그리고 메서드는 외부로부터 숨겨지고 메시지만 외부에 드러난다.
좋은 메세지 작성하기
What/Who 사이클 : 어떤 객체가 필요한지 보다 무엇을 해야할지 먼저 생각하자. 책임 => 객체 순서로 가야 한다.
묻지 말고 시켜라 : 묻는 행위는 객체에 초점을 맞추게 한다. 그냥 시키는 식으로 만들어서 메세지 자체에 집중하도록 하자.
메세지를 믿어라 : 메세지의 전송자가 누구던 전송자는 메세지에 함축된 동작의 결과를 받을 것이고 메세지의 수신자가 누구던 수신자는 해당 메세지가 요구하는 동작을 수행할 것이다.
인터페이스, 다형성
인터페이스는 메세지의 집합이다.
인터페이스는 사용자 객체에게는 특정 객체를 사용하기 위해 가지고 있어야 할 정보의 양을 줄여주고 협력자 객체에게는 변경이 되는 부분을 구분해주는 역할을 한다.
또 인터페이스는 다형성을 제공한다. 특정 인터페이스만 만족하면 어떤 객체든 협력자로 역할을 할 수 있다.
6. 객체 지도
기능 vs 구조
소프트웨어의 일차적인 목표는 기능이다. 결국 특정 시스템은 사용자의 요구사항에 맞는 기능을 수행해야 한다.
하지만 기능은 사용자의 요구사항에 맞춰서 끊임없이 변경한다. 그래서 시스템을 만들 때 사용자의 요구사항이 변해도 변경 사항이 최소화될 수 있는 구조를 만들어두는 것이 중요하다. 구조 안에 기능을 녹여서 변화에 안정적인 소프트웨어를 개발하는 것이 설계의 목표다.
불안정한 기능(유스케이스)
기능은 소프트웨어가 존재하는 이유이다. 그리고 유스케이스는 특정 시스템의 기능을 명확하게 표현하는 방법 중에 하나이다.
유스케이스
1. 사용자와 시스템의 상호작용을 이야기 흐름으로 보여주는 텍스트임, 다이어그램에 노력을 쏟지 말자 (얻는게 없다.)
2. 여러 시나리오의 집합이다. 참고로 시나리오를 유스케이스 인스턴스라고 부른다.
3. 유스케이스는 단순한 피처 목록(시스템의 기능) 나열이 아니다.
4. 유스케이스는 사용자 UI 등 세부정보를 표현하지 않는다.
5. 유스케이스는 내부 설계와 관련된 내용을 전혀 포함하지 않는다.
예시
유스케이스 명 : 중도 해지 이자액을 계산한다.
일차 액터 : 예금주
주요 성공 시나리오 :
1. 예금주가 정기 예금 계좌를 선택한다.
2. 시스템은 정기예금 계좌 정보를 보여준다.
3. 예금주가 금일 기준으로 예금을 해지할 경우 지급 받을 수 있는 이자 계산을 요청한다.
4. 시스템은 이를 계산한 후 결과를 사용자에게 제공한다.
안정된 구조(도메인 모델)
도메인 모델: 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태
도메인 모델은...
- 도메인 모델을 구성하는 개념은 비즈니스가 없어지거나 개편되지 않는 이상 안정적으로 유지된다.
- 도메인 모델을 구성하는 개념 간의 관계는 비즈니스 규칙을 기반으로 하기 때문에 비즈니스 정책이 크게 변경되지 않는 한 안정적으로 유지된다.
우리는 시스템의 안정된 구조를 설계하기 위해 도메인 모델을 활용할 수 있다. 다만 현실 속 도메인 모델과 소프트웨어 세계는 엄연히 다르니 무작정 배끼지 말고 필요한 부분만 잘 차용하는 지혜가 필요하다.
기능 + 구조
하나의 거대한 시스템 구상하기, 유스케이스로 기능 구체화
거대한 시스템을 작은 책임으로 분할하기, 책임 주도 개발
책임을 수행할 객체 선택하기, 도메인 모델에서 참고 가능
7. 함께 모으기
객체 지향 세계에서는 동일한 클래스를 세 가지 관점으로 바라볼 수 있다.
개념 관점 : 해당 클래스가 도메인의 어떤 개념을 표현하는지.
명세 관점 : 해당 클래스의 객체는 소프트웨어 세상에서 어떤 책임을 수행하는지.
구현 관점 : 해당 클래스의 객체는 어떻게 구현되는지
잘 짜여진 클래스는 세 가지 관점이 잘 드러나도록 개념, 인터페이스, 구현을 함께 가지고 있어야 한다.
