OOP) 오브젝트 디자인

객체의 지도

---

객체를 설계함에 있어서 어떤 고민을 해볼 지 생각해 보자

---

기능과 구조

지금 부엉이가 친구 병아리를 만나려고 한다.

그래서 병아리는 부엉이에게 자신의 위치를 알려준다.

1. ➡️ 으로 2블럭
2. ⬆️ 으로 2블럭

이렇게 위치를 설명해 주었다.

이렇게 집을 찾을 수 있었다.

그런데 만약 부엉이가 시작점이 변경된다면?

과연 위에 길안내는 유효할 것인가?

1. ➡️ 으로 1블럭
2. ⬆️ 으로 2블럭

으로 길 안내가 변경 되었다.

---

부엉이(사용자)가 위치설명(목표)를 위해 요청 했을 때, 부엉이의 위치(사용자의 상황-요구사항) 에 따라서 절차(기능)들이 변경되었다.

이처럼 특정 요구사항 마다 ,

기능들이 변경되었다,

하지만 구조적으로 접근을 했다면, 다른 결과를 얻을 수 있다.

부엉이에게 이런 지도(구조)를 손에 쥐어 준다면 , 어떤 상황에서도 재사용이 가능해 졌을것 이다.

이처럼

요구사항이 변경됨에 따라서 기능들은 쉽게 변한다.

사용자의 요구사항은 항상 변한다는 것을 항상 인지할 필요가 있다.

기능은 꾸준히 변경될거다.

우리는 기능에 의존하여 소프트웨어를 만들게 되면 하나의 요구사항 변경에 많은 연쇄적인 수정을 겪어야할 지도 모른다.

---

도메인 과 유스케이스

도메인모델링은 구조를 수집하고 표현하는 기법이고 ,

유스케이스모델링은 기능을 수집하고 표현하는 기법이다.

두개를 올바르게 적절하게 이용하여 , 우리는 설계를 해야할 것이다.

우리가 개발하는 시스템 또는 라이브러리 등 , 소프트웨어의 본질에 대해 제일 잘 아는 건 의외로 사용자이다.

유스케이스모델에서 본질을 이용하기 위해서 사용자는 소프트웨어를 사용하기 떄문이다.

사용자는 소프트웨어를 어떻게 판단하고 어떠한 목적으로 사용을 할까??

대부분 어떤 목표가 있다. 즉 원하는 기능을 위해서 그 소프트웨어를 선택하고 사용한다.

우리는 사용자가 원하는 기능을 구체적으로 정확히 파악할 필요가 있다.

늦잠을 많이 자는 부엉이는 알람기능을 해주는 소프트웨어를 원한다.

원하는 시간에 알람을 맞추면 , 설정된 시간에 벨이 큰소리로 울리고

버튼 클릭시 알림이 종료되는 알람어플로 아침에 늦지않게 일찍

기상할 수 있기를 원한다.

정리해보자

1. 사용자가 원하는 시간을 설정한다.
2. 해당 시간이 되면 알람소리를 발생시킨다.
3. 버튼클릭시 알람이 종료된다.

알람어플에서 사용할 기능의 큰 본질은 *설정된 시간에 알람을 발생시키는 것 * 이다.

위의 기능 나열을 보면 사용자와의 상호작용에 대해 텍스트화 시켜 둔 것이다,

어떤 기능이 필요한 기능을 유스케이스로 텍스트화해서 정리해두되 , 언제나 수정될 수 있다는 걸 인지 하고 있어야한다.

사용자가 보는 관점에서의 기능을 정의해두고, 그 외부에서 시스템이 해주길 바라는 동작을 하기 위한 부수적인 동작들은 감추어 두고,

객체의 책임을 나누는 과정을 나누는 구조로 구조화 한다면 , 변할 수 있는 기능에 따른 연쇄적인 수정에 대해서 방어적인 프로그래밍이 가능할 것이다.