Jaehyun Baek
home
·
wiki
·
about
·
search
객체지향의 사실과 오해 갈무리
역할, 책임, 협력 관점에서 본 객체지향
2019-04-13
01. 협력하는 공동체
객체지향은 단순한 현실 세계의 모방이 아니다.
객체가 현실 세계의 객체와는 전혀 다르다는 사실은 객체지향 분석/설게에 관한 전통적인 관점을 송두리째 흔들기에 충분하다.
협력 - 역할 - 책임
여러 사람들이 동일한 역할을 수행할 수 있다. 커피를 캐셔가 주문 받든, 바리스타가 주문 받든 상관없다.
역할은 대체 가능성을 의미한다. 요청자 입장에서는 어떤 사람이 역할을 수행해도 문제 없다.
책임을 수행하는 방법은 자율적으로 선택할 수 있다.
한 사람이 동시에 여러 역할을 수행할 수 있다.
클래스의 구조와 메서드가 아니라 객체의 역할, 책임, 협력에 집중하라. 객체지향은 객체를 지향하는 것이지 클래스를 지향하는 것이 아니다.
02. 이상한 나라의 객체
객체란 인간이 분명하게 인지하고 구별할 수 있는 물리적인 또는 개념적인 경계를 지닌 어떤 것이다.
객체는 자동차처럼 만질 수 있는 구체적인 사물일 수도 있고, 시간처럼 추상적인 개념일 수도 있다.
입문한 사람들이 가장 쉽게 빠지는 함정은 상태 중심으로 객체를 바라보는 것이다.
03. 타입과 추상화
추상화의 수준, 이익, 가치는 목적에 의존적이다.
"현상은 복잡하다. 법칙은 단순하다. 버릴 게 무엇인지 알아내라."
데이터 타입은 메모리 안에 저장된 데이터의 종류를 분류하는 데 사용하는 메모리 집합에 대한 메타데이터다.
행동이 우선이다. 객체의 타입을 결정하는 것은 객체의 행동뿐이다.
훌륭한 객체지향 설계는 외부에 행동만을 제공하고 데이터는 행동 뒤로 감춰야 한다. 이 원칙을 흔히 캡슐화라고 한다.
04. 역할, 책임, 협력
객체의 책임은 '객체가 무엇을 알고 있는가'와 '무엇을 할 수 있는가'로 구성된다.
하는 것: 객체를 생성하거나 계산, 다른 객체에 행동을 시키는 것. 다른 객체의 활동을 제어
아는 것: 개인적인 정보, 관련된 객체, 자신이 유도하거나 계산할 수 있는 것
역할은 다른 객체에 의해 대체 가능함을 의미한다.
설계 기법
책임 주도 설계
디자인 패턴
테스트 주도 개발
05 책임과 메시지
포괄적이고 추상적인 책임을 선택한다고 해서 무조건 좋은 것은 아니다. 책임이 수행 방법을 제한할 정도로 너무 구체적인 것도 문제지만 협력의 의도를 명확하게 표현하지 못할 정도로 추상적인 것 역시 문제다.
메시지 중심으로 협력을 설계해야 한다.
객체의 행위를 결정하는 것은 객체 자체의 속성이 아니라는 점에 주목하라.
어떤 객체도 섬이 아니라는 말은 협력이라는 문맥 안에서 객체의 책임과 역할을 결정하라는 의미를 내포하고 있다.
묻지 말고 시켜라
'어떻게'에서 '무엇'으로 전환하는 것은 객체 인터페이스의 크기를 급격하게 감소시킨다.
메시지를 믿어라.
인터페이스와 구현의 분리 원칙이 왜 중요한가? 그것은 소프트웨어는 항상 변경되기 때문이다. 수많은 객체들이 물고 물리며 돌아가는 객체지향 공동체에서 어떤 객체를 수정했을 때 어떤 객체가 영향을 받는지를 판단하는 것은 거의 곡예에 가깝다.
06 객체 지도
유일하게 변하지 않는 것은 모든 것이 변한다는 사실뿐이다. - 헤라클레이토스
길을 직접 알려주는 방법이 기능적이고 해결 방법 지향적인 접근법이라면 지도를 이용하는 방법은 '구조적이고 문제 지향적인 접근법'이다. 지도는 길을 찾는 데 필요한 구체적인 기능이 아니라 길을 찾을 수 있는 '구조'를 제공한다.
모든 소프트웨어 제품의 설계는 두 가지 측면이 존재한다. 하나는 기능측면의 설계이고, 다른 하나는 구조 측면의 설계이다. 기능 측면의 설계는 제품이 사용자를 위해 무엇을 할 수 있는지에 초점을 맞춘다. 구조 측면의 설계는 제품의 형태가 어떠해야 하는지에 초점을 맞춘다.
07 함께 모으기
구현하지 않고 머릿속으로만 구상한 설계는 코드로 구현하는 단계에서 대부분 변경된다. 설계 작업은 구현을 위한 스케치를 작성하는 것이다.