- 저자
- 조영호
- 출판
- 위키북스
- 출판일
- 2015.06.17
이상한 나라의 객체지향
프로그래밍을 처음 배울 때부터 객체지향은 매우 이상했다.
처음 만나게 된 Visual Basic부터 C#, Java에 이르기까지 도통 정체를 알 수 없는 녀석이다.
언어를 처음 배울 때 변수, 배열, 반복문, 제어문까지 잘 지나가다가 '그 녀석'을 만나면 항상 장벽에 가로막힌 느낌이었다.
객체, 클래스, 인스턴스, 메서드, 상속, 인터페이스 등 다양한 개념들이 쏟아지는데
이를 어디에 어떻게 쓰라는 건지 알 수 없었다.
나름 설명을 해 준다는 것이 자동차나 붕어빵을 예로 들었다.
물론 객체지향의 초입에는 그런대로 설명이 통했지만, 점점 깊이 들어갈수록 머릿속은 미궁에 빠져버렸다.
그때 마주한 객체지향은 말 그대로 '이상한 나라'였다.
그 '이상한 나라'는 정보처리기사 자격증을 준비하면서 또다시 만나게 된다.
객체지향은 여기서도 꽤나 비중 있게 등장한다.
객체 지향의 특징 - 추상화, 상속, 다형성, 캡슐화 - 이라거나, SOLID 원칙, 디자인 패턴(정말 고통스러웠다) 등
또 다른 개념들을 밀어 넣었다.
도대체 정체가 무엇인지 궁금했다.
실마리가 될 책을 발견하다
그렇게 골머리를 앓는 중에, 한 책을 발견하게 된다.
[객체지향의 사실과 오해]는 지금까지 보았던 언어 서적들이 객체지향을 클래스 위주로 설명한 것과 달리,
"역할-책임-협력의 관점에서 본 객체지향"이라는 것이 새롭게 다가왔다.
책을 구입한 지 오래되었지만, 그동안 객체지향에게 당한 것 때문인가, 선듯 손이 가지 않았다.
그래도 이번에 끝장을 보자는 마음에서 일독을 성공했다.
[객체지향의 사실과 오해] 감상평
'내가 정말 객체지향을 오해했구나'라는 생각을 많이 느끼게 해 준 책이다.
한편, 클래스를 위주로 설명한 책과 강사분들께 배신감을 느꼈지만, 왜 그렇게 했는지 어느 정도는 이해할 수밖에 없었다.
책은 기술 서적임을 떼고서 보더라도 매우 친절하게 설명했다.
코딩에 관해서 모르는 사람도 친절한 예시와 그림을 통해서 쉽게 읽을 수 있을 것이라 예상한다.
같은 말이 자주 반복되어 살짝 늘어지는 기분이 들 수도 있다.
이제 객체지향에 대해 지금처럼 방황하지 않고, 나설 수 있게 되었다고 생각한다.
실제 코드 작성은 다른 이야기겠지만 말이다.
그럼에도 불구하고 나처럼 객체지향을 오해해서 길을 헤매고 있다면
[객체지향의 사실과 오해]를 강력하게 추천한다.
아래는 책을 읽고 나름대로 요약하였다. 거기에 내 나름대로 풀이해 보았다.
[객체지향의 사실과 오해] 요약
객체 지향과 객체
객체지향
- 목표를 달성하기 위해 자율적인 객체가 메시지를 통해 서로 협력하는 방식
- 객체지향은 새로운 세계를 만들어 내는 것이다.
- 객체지향의 품질은 적절한 객체와 적절한 책임이 결정한다.
객체지향은 실제 세계의 모방이 아니다.
위에서 말했듯이 자동차와 붕어빵도 객체가 될 수 있지만 객체지향의 세계에서 객체는 현실의 제약을 받지 않는다.
예를 들어 오늘날 소프트웨어 오류를 '버그'라고 말하지만 실제로는 컴퓨터 어디에도 벌레는 존재하지 않듯이.
또는 클라우드 컴퓨팅은 하늘의 구름과 전혀 상관없는 것처럼 말이다.
즉, 객체지향은 새로운 세계를 창조하는 것이다.
(현실을 뛰어넘는다는 점에서 판타지 소설이라고 생각하면 좋을 것 같다)
객체
협력에 참여하는 자율적인 주체
객체의 자율성을 위해 내부는 철저히 숨겨서 협력의 구체적인 방법은 스스로 결정한다.
이를 위해서 스스로의 상태와 행동을 안다.
객체의 구성요소
- 상태: 객체가 가진 특정 시점의 구조 정보 → 과거 행동의 결과
- 행동: 요청에 응답하기 위한 동작과 반응
행동의 결과로 자신의 상태를 바꾸거나, 다른 객체에게 요청(메시지)한다. - 식별자: 객체간 구분을 위한 정적인 상태
객체의 상태는 행동에 의해서만 변경된다.
추상화와 개념, 타입
새로운 세계의 창조는 추상화라는 도구를 사용한다. 그 결과 개념을 만들어낸다.
추상화는 객체의 행동을 통해 특징과 의미를 뽑아내어 개념을 이룬다.
이를 통해 변화하는 객체의 복잡성을 해결한다.
객체의 행동이 개념(= 타입)을 결정하므로 타입에 따라 데이터 사용 방법을 분류하고 잘못 연산되지 않도록 방지한다.
즉, 타입은 객체가 데이터를 다루는 방법과 객체 간 상호작용 하는 방법이다.
클래스는 단지 정적 타입을 구현하는 대표적인 방법에 불과하다.
그래서 우리는 "클래스 지향"이라고 부르지 않는다.
클래스 또한 수단에 불과하며, 객체의 행동에 집중해야 한다. (프로토타입 언어는 다른 방식으로 객체를 구현한다.)
그리고 클래스는 다양한 역할-코드 재사용, 상속 등의 다양한 역할을 하기에 혼동했던 것 같다.
추상화 기법
- 분류 - 인스턴스 ~ 타입(집단) - 인스턴스 객체(개인)
- 일반화 - 특수화 ~ 슈퍼 타입(대범주) - 서브 타입(소범주)
- 집합 - 분해 ~ 전체 구조 - 부분 구성요소
객체의 책임
객체는 적극적으로 협력에 참여할 의무를 진다.
요청(메시지)에 따라 적절한 행동을 해야 한다.
객체의 자율적인 행동 → 메시지 = 책임
객체의 자유로운 처리 방식 → 다형성
- 책임 주도 설계: 객체에게 협력에 필요한 적절한 책임을 부여한다.
- 디자인 패턴: 책임 주도 설계의 결과물. 특정한 문제를 해결하기 위해 역할-책임-협력을 미리 설계해 둔 기출유형집
- 테스트 주도 설계: 객체의 역할-책임-협력이 적절한지 예측 및 피드백
객체의 책임은
객체가 어떻게 처리하는가를 설명하는 것이 아닌,
무엇을 하는지를 설명하는 것이다.
인터페이스
두 사물이 마주치는 경계점에서 서로 상호작용하는 방법 또는 장치
인터페이스의 특징
- 인터페이스를 알면 내부 구조를 몰라도(변경되어도) 상호작용할 수 있다.
- 인터페이스만 동일하다면 대상이 변경되어도 상호작용 할 수 있다.
객체지향에서의 인터페이스
- 좀 더 추상적인 인터페이스: 너무 상세하면 객체의 자율성을 위협한다. → 좀 더 추상적으로 표현하라.
- 최소 인터페이스: 사용하지 않는 것은 노출하지 마라. → 필요한 것만 노출시키고 메시지를 따라라.
- 인터페이스와 구현의 분리: 객체의 자율성이 위협받지 않도록 구역을 분리한다.
- 공용 인터페이스: 객체의 외부 → 위험 지대, 성 밖의 국경검문소 또는 검역소
- 구현: 객체의 내부, 공용 인터페이스를 제외한 상태의 표현, 메서드 코드 등 → 안전지대, 성 안의 마을
구조와 기능
객체지향은 안정적인 구조를 따라 역할-책임-협력을 구성한다.
구조
사용자가 도메인(특정 분야)에 대해서 생각하는 개념이나 관계
개념은 쉽게 바뀌지 않기 때문에 안정적이다.
도메인 모델(구조의 수집과 표현)
도메인을 선택적으로 단순화하고 의식적으로 구조화한 형태
일종의 멘탈 모델: 자신이 자기 자신 또는 타인, 환경과 상호작용하는 모형
최종 제품을 통해서만 사용자와 설계자가 소통할 수 있으므로, 모델을 정확하게 반영해야 한다.
- 도메인 모델 → 프로그래밍 설계 = 연결완전성
- 코드 구조 → 도메인 = 가역성
기능
목표를 달성하기 위해 (책임을 수행하는) 시스템의 행동
기능 기반으로 설계하면 기능이 변경되므로, 소프트웨어 전체가 불안정해질 수 있다.
유스케이스(기능의 수집과 표현)
시스템과 사용자의 상호작용을 텍스트로 표현한 것
그림이 아니라 스토리(시나리오)의 표현이다.
단순 기능 목록, 사용자 인터페이스, 내부 설계는 포함되지 않는다.
객체 지향 설계의 관점
- 개념 관점: 도메인의 개념과 관계 → 도메인 추상화
- 명세 관점: 객체의 인터페이스 - 무엇(What)을 할 수 있는가? → 공용 인터페이스
- 구현 관점: 실제 코드 구현 - 어떻게(How)할 것인가? → 속성, 메서드