[개발자 책읽기] 객체지향의 사실과 오해-조영호 (6장 객체 지도)

 

해당 글은 조영호님의 객체지향의 사실과 오해 역할, 책임, 협력, 관점에서 본 객체지향 라는 책을 읽고 학습한 내용을 정리 및 회고하는 글 입니다. 자세한 사항은 YES 24 객체지향의 사실과 오해 에서 확인해주세요.

객체지향의 사실과 오해 - 역할, 책임, 협력 관점에서 본 객체지향 (조영호)

• 위키북스
• 지은이: 조영호
• 펴낸이: 박찬규, 엮은이: 이대엽, 디자인: 북누리
• 1쇄 발행: 2015.06.17

---

이번 장에서 이야기하고자 하는 것

• 객체 지도
  • 초행길에서 모르는 길을 갈 때 목적지 까지 잘 가는 방법 2가지
    1. 해당 지역의 주민에게 물어본다.
    2. 지도를 확인한다.
  • 1번은 길을 찾으려는 목적 지향적 방법
    • 특정 목적을 수행하기 위함
    • 다른 목적이 파생되면 적용 불가
  • 2번은 추상화된 길을 스스로 찾으려는 구조 지향적인 방법
    • 특정 목적을 수행하기 위해서 더 많은 노력이 필요
    • 다른 목적이 파생될 때 유리
  • 1번은 레거시 시스템에 자주 사용되는 기능 추가 (특정 기능을 설계)
    • 특정 기능에 맞춰서 구조가 결정
  • 2번은 객체지향 설계에 빈번하게 사용되는 기능 종속 (특정 구조를 설계)
    • 구조에 따라서 특정 기능이 결정
• 기능 설계 vs 구조 설계
  • 모든 소프트웨어 설계에는 기능, 구조 측면의 설계가 존재
    • 기능
      • 특정 사용자가 무엇을 할 수 있는지에 초점
    • 구조
      • 제품의 형태가 어떻게 되어야 하는지에 초점
  • 훌륭한 소프트웨어는 새로운 기능에 대한 변화와 수용이 민첩해야 함
  • 개발자의 삶이 고단한 이뉴는 요구사항이 끊임 없이 변경되기 때문임
    • 이를 피하는 방법은 존재하지 않음
    • 이를 피하기 보다는 변경을 수용하는 쪽으로 발전시키는게 맞음
• 객체지향 설계의 두 가지 재료
  • 사용자에게 제공할 기능과 기능을 담을 안정적인 구조가 필요
    • 기능은 사용자의 목표에 정확이 일치해야 함
      • 유스케이스 모델링을 이용
      • 유스케이스 모델은 객체지향 설계 도구도 설계 기법도 아님
      • 이는 단지 사용자가 바라보는 시스템 외부 관점만 존재
        • 시스템 내부 구조나 실행 메커니즘에 관한 어떠한 정보도 제공하지 않음
        • 단지 상호작용만 존재
    • 구조는 기능 변경을 수용할 수 있도록 안정적이어야 함
      • 도메인 모델링을 이용
      • 우리는 결과적으로 구조는 도메인 모델링에 모습과 유사해야 함
      • 유스케이스와 반대로 시스템 내부와 행동까지 담고 있기 때문에 안정적임
        • 도메인의 본질을 잘 나타내고 있음
        • 객체지향 설계에서는 도메인 모델리을 자주 사용하면 좋음
• 안정적인 도메인 모델을 기반으로 한 시스템을 구현해야 유지보수가 편하고 유연한 객체지향 시스템이 된다

나의 해석과 회고

또 어김없이 이번 장에서는 조영호 개발자님의 발표 애플리케이션 아키텍처와 객체지향 가 떠올랐다.

 

영화 예메 시스텡믈 설계할 때 도메인에 대한 설계가 다음과 같이 이루어졌다고 가정해보자.

 

만약 해당 도메인에 대한 적절한 도메인 모델링을 수행한다면 도메인 모델링은 다음과 같이 나와야 한다.

 

이 둘은 거의 비슷한 형태로서 존재하게 되는데, 1대1 대응이 될 정도로 비슷한 구조를 띄는 것을 알 수 있다.

---

나는 이 책을 읽기 전에 먼저 애플리케이션 아키텍처와 객체지향의 발표를 보게 되었는데, 처음에 발표를 봤을 때 아주 추상적인 것들이 점점 책을 읽을 때 마다 더 잘 와닫고 이해가 가기 시작함을 느꼈다.

이 책의 구현? 실무? 부분도 존재하는데, 바로 오브젝트!

현재 이 책도 읽기 위해 준비중이며 아주 기대가 된다.