객체의 지도
객체를 설계함에 있어서 어떤 고민을 해볼 지 생각해 보자
기능과 구조
지금 부엉이가 친구 병아리를 만나려고 한다.
그래서 병아리는 부엉이에게 자신의 위치를 알려준다.
- ➡️ 으로 2블럭
- ⬆️ 으로 2블럭
이렇게 위치를 설명해 주었다.
이렇게 집을 찾을 수 있었다.
그런데 만약 부엉이가 시작점이 변경된다면?
과연 위에 길안내는 유효할 것인가?
- ➡️ 으로 1블럭
- ⬆️ 으로 2블럭
으로 길 안내가 변경 되었다.
부엉이(사용자)가 위치설명(목표)를 위해 요청 했을 때, 부엉이의 위치(사용자의 상황-요구사항) 에 따라서 절차(기능)들이 변경되었다.
이처럼 특정 요구사항 마다 ,
기능들이 변경되었다,
하지만 구조적으로 접근을 했다면, 다른 결과를 얻을 수 있다.
부엉이에게 이런 지도(구조)를 손에 쥐어 준다면 , 어떤 상황에서도 재사용이 가능해 졌을것 이다.
이처럼
요구사항이 변경됨에 따라서 기능들은 쉽게 변한다.
###사용자의 요구사항은 항상 변한다는 것을 항상 인지할 필요가 있다.
기능은 꾸준히 변경될거다.
우리는 기능에 의존하여 소프트웨어를 만들게 되면 하나의 요구사항 변경에 많은 연쇄적인 수정을 겪어야할 지도 모른다.
도메인 과 유스케이스
도메인모델링은 구조를 수집하고 표현하는 기법이고 ,
유스케이스모델링은 기능을 수집하고 표현하는 기법이다.
두개를 올바르게 적절하게 이용하여 , 우리는 설계를 해야할 것이다.
우리가 개발하는 시스템 또는 라이브러리 등 , 소프트웨어의 본질에 대해 제일 잘 아는 건 의외로 사용자이다.
유스케이스모델에서 본질을 이용하기 위해서 사용자는 소프트웨어를 사용하기 떄문이다.
사용자는 소프트웨어를 어떻게 판단하고 어떠한 목적으로 사용을 할까??
대부분 어떤 목표가 있다. 즉 원하는 기능을 위해서 그 소프트웨어를 선택하고 사용한다.
우리는 사용자가 원하는 기능을 구체적으로 정확히 파악할 필요가 있다.
늦잠을 많이 자는 부엉이는 알람기능을 해주는 소프트웨어를 원한다.
원하는 시간에 알람을 맞추면 , 설정된 시간에 벨이 큰소리로 울리고
버튼 클릭시 알림이 종료되는 알람어플로 아침에 늦지않게 일찍
기상할 수 있기를 원한다.
정리해보자
- 사용자가 원하는 시간을 설정한다.
- 해당 시간이 되면 알람소리를 발생시킨다.
- 버튼클릭시 알람이 종료된다.
알람어플에서 사용할 기능의 큰 본질은 **설정된 시간에 알람을 발생시키는 것 ** 이다.
위의 기능 나열을 보면 사용자와의 상호작용에 대해 텍스트화 시켜 둔 것이다,
어떤 기능이 필요한 기능을 유스케이스로 텍스트화해서 정리해두되 , 언제나 수정될 수 있다는 걸 인지 하고 있어야한다.
사용자가 보는 관점에서의 기능을 정의해두고, 그 외부에서 시스템이 해주길 바라는 동작을 하기 위한 부수적인 동작들은 감추어 두고,
객체의 책임을 나누는 과정을 나누는 구조로 구조화 한다면 , 변할 수 있는 기능에 따른 연쇄적인 수정에 대해서 방어적인 프로그래밍이 가능할 것이다.