본문 바로가기

책 - 내용 정리

객체지향의 사실과 오해


 
부제 : 역할, 책임, 협력 관점에서 본 객체지향

 책에서 말하고자 하는 내용은 부제에 쓰여진 객체의 역할, 책임, 협력에 대한 중요성과 비유(이상한 나라의 엘리스, 커피집 등..)를 통한 독자의 이해를 돕고 있다.
 2달에 걸쳐서 짬짬히 읽어서 전체 내용을 세세하게 읽지는 못했지만, 인상 깊었던 내용을 남겨본다.

1. 오해 : 객체지향세계와 현실세계의 차이점?
  • 처음 자바 개발을 접하면서 “현실세계와 똑같이 객체를 설계하지 못해서 스스로를 많이 자책 했었다”
  • 그리고 지금까지도 찜찜함으로 남아 있던 해답을 이 책에서 찾을 수 있었다.
    • 요약
      • 객체지향을 이해하기 위해서 실세계의 모방이라는 개념은 아주 훌륭한 개념이다.
      • 하지만, 이것은 객체지향을 이해하는데 걸림돌이 되는 과거의 인습일 뿐이다.
      • 현실 속의 객체와 소프트웨어 객체 사이의 가장 큰 차이점은 무엇일까? 그것은 현실 속에서는 수동적인 존재가 소프트웨어 객체로 구현될때는 능동적으로 변한다는 것이다.
        • 현실 세계에서의 기능 이상의 능력을 가질 수 있다.(구현하기 나름)
          • 예) 
            • 능동적인 행동
            •  현실 상태 이상의 상태값
            • ….
        • 생각해보니 현실세계와 유사하게 만들려는 노력은 게임프로그래머들이 가장 노력하는거 같다.
          • 탄도 계산
          • 물리 움직임 등..
      • 내가 구현하는 도메인과 서비스가 반드시 현실세계를 모방해야만 한다는 오해는 하지말자.
2.사실
  • 타입과 추상화
    • 타입
      • 타입은 개념이다.
        • 사실, 프로그래밍 상에서 Type은 메모리상에 0,1로 표현된 데이터일 뿐, 사람이 정의한 개념을 표현하게 된다.
      • 공통점을 기반으로 객체들을 묶기 위한 틀이다.
    • 추상화
      • 객체들의 복잡함을 극복해보자.
      • 공통점을 묶자. 
  • 객체
    • 행동이 우선이다.
      • 객체가 어떤 행동을 하느냐에 따라 객체의 타입이 결정된다.
    • 역할, 책임, 협력
      • 책임의 분류(크레이그만)
        • 어떤 일을 하는것(객체의 행동)
        • 어떤 것을 아는것(객체가 가지는 상태)
      • 역할
        • 책임의 집합이다.
        • 역할 별로 객체를 나눈다면, 내가 만들 클래스들을 알 수 있게 될거 같다.
    • 오류 : 객체는 데이터의 상태를 저장하기 위해 존재하는 것이다?
      • 사실이지만, 더 중요한 존재이유는 객체의 행위를 수행하면서 서로 협력하기위해서다.
  • 객체지향 설계 기법
    • 책임-주도 설계(Responsibility-Driven-Design)
    • 디자인 패턴 - GoF
    • 테스트-주도 개발(Test-Driven-Development)
      • 책임-주도 설계를 통해 도달해야하는 목적지를 테스트라는 안전장치를 통해 좀 더 빠르고, 견고하게 도달하는 방법
        • 책임-주도 설계가 기본이 되야 가능하다.
      • 책을 읽어봤을 때 테스트 주도 개발에 실패하는 이유
        • 책임-협력의 관점에서 객체를 바라보는 훈련이 부족한 경우.
          • 책임-주도 설계를 잘못하는 경우를 말하는거 같다.
      • 현실적으로 실패하는 이유?
        • 회사에서의 실패
          • 부족한 개발 시간.
            • 미숙함에서 오는 퍼포먼스 저하.
        • 생각해보니 회사에서 진행하는 업무에 처음 해보는 테스트 주도 개발을 적용하는 내가 바보인거 같다..
          • 먼저 개인 프로젝트에서 진행하고 익숙해지고 편해졌을 때 적용하는게 좋을거 같다..
            • 물론 끈기있게 야근을 계속하면, 할수 있을지도 모르겠다.
          • 처음이라면 무작정보다는 개인 프로젝트에서 먼저 익숙해지자.
  • 메시지와 메서드
    • 객체간의 메시지를 주고 받기 위해서는 메서드를 이용한다.
      • Public 응답내용 doIt (전달 내용){
      • }
    • 다형성: (책을 읽고 내가 생각해왔던 다형성을 다른 관점으로도 생각해봄)
      • 서로 다른 유형의 객체가 동일한 메시지에 대해 서로 다르게 반응하는 것. 
    • 메시지가 인터페이스를 결정한다.(메시지가 정해지면, 인터페이스를 쉽게 정의할 수 있다.)
      • 인터페이스가 구현중에 변한다고 해서 부끄러워 말자!
      • 인터페이스는 구현전에 설계 과정에서 예측하는 과정이기 때문에 구현중에 바뀔수도 있다!.
  • 객체 지도
    • 객체 지도
    • 도메인 모델, 유스케이스, 그리고 책임-주도 설계
      • 도메인 모델
        • 필요한 객체를 정의
      • 유스케이스
        • 유스 케이스를 통해서 객체 행위 정의
        • 필요한 메시지(메소드) 정의
      • 책임-주도 설계
        • 객체들의 협력 공동체를 만들어 내자
    • 객체 지도 부분은 개발을 진행하기 전에 설계되야할 핵심 내용을 잘 설명해 준거 같다.
      • 무조건 개발을 먼저 시작했거나
      • 처음 개발을 뭐 부터 시작해야할지 모르겠을 때
      • 도움이 많이 될거 같다.
  • 인터페이스와 구현을 분리하라.



-
 개발하다보면 어느새인가 생각 없이 개발을 하던 습관에서 벗어나,

 좀 더 객체지향적으로,

 좀 더 의식적으로 개발 해야겠다..!