객체지향의 사실과 오해를 읽고, 01
객체지향의 사실과 오해
서론
<img src="https://static.podo-dev.com/blogs/images/2019/12/11/origin/41827e8f-3922-4ac8-a1ab-b5cba87aacc3.png" alt="f0081118_559a8edd4aab1.png" style="width:360px;">
개발자 조영호님이 쓰신 책이다. (감사합니다..)
<br>
그래도 나는 학부 시절에 나름 공부를 열심히 하는 학생이었다... (..)
그리고 유능한 교수님(실제로 매우 잘가르치시는)의 강의에,
객체지향 언어인 Java
를 학습하였다.
<br>
그리고 우리가, 보통의 학부시절에 배우는 내용은 이렇다
- 객체 : 실세계의 사물
- 객체지향언어 : 객체들관의 관계를 통해 개발하는 언어
- 상속 : 상위클래스의 멤버변수와, 메소드를 사용하여, 재사용성을 높임
- 캡슐화 : 관련있는 변수를 묶고, 내부를 숨김
- 인터페이스 : 추상메소드와, 상수만가지는 클래스, 생성불가
- 추상클래스 : 추상메소드를 가지거나 abstract 키워드를 가진 클래스 , 생성불가
<br>
그리고 이책을 읽고
내가 알고있던것이 정말 객체지향인 것일까?
라는 생각이 머리에 돌았다.
실제 세계의 커피
를
Coffee
라는 클래스로 정의하면, 그것이 객체지향적인것일까?
<img src="https://static.podo-dev.com/blogs/images/2020/01/10/origin/057148d9-e8d9-48cf-bbf6-6c352e5bb911.png" alt="base64.png" style="width:474px;">
시무룩..
<br>
객체지향의 오해
객체 지향 세계는 실세계를 모방해서 만들어집니다.
실제세계를 컴퓨터 세계로 가져오는 것입니다. (?)
객체지향의 가장 큰 오해는,
객체지향의 목표가 실세계를 모방한다는 것이다.
객체지향이란 실세계를 모방하는 것이 아닌,
새로운 객체의 세계를 창조하는 것이다
하지만, 우리가 객체 지향을 이해하기에
실세계를 빗대어 표현하는것은 아주 좋은 예시가 될 수 있다.
그래서 자연스럽게 실세계를 빗대어 객체의 세계를 표현하였고,
그 결과, 우리는 객체지향을 실세계의 모방
이라고 착각을 한다.
<br>
실세계의 예시
앞서의 내용처럼,
실세계는 객체의 세계를 이해하기에 좋은 예시가 된다.
예시로서, 실세계를 우선 이해 해야한다.
실세계의 우리는 협력을 한다.
커피를 주문하는 협력을 살펴보자.
<img src="https://static.podo-dev.com/blogs/images/2020/01/10/origin/7c8096f6-18b8-49cf-b3bf-279064d1d790.png" alt="base64.png" style="width:240px;">
- 손님 : 따듯한 아메리카노 한잔주세요!
- 캐셔 : 네 주문받았습니다, 바리스타님 따아 하나요!
- 바리스타 : 넵, 따아 만들게요 ~ 따아 나왔습니다!
- 캐셔 : 손님, 따듯한 아메리카노 나왔습니다.
- 손님 : 감사합니당.
<br>
커피를 만드는 과정을 살펴보면,
각자
의 영역에서 역할
이 정해져있고,
역할
에 따른 책임
을 가지고 있는다.
손님
은 주문을 할 책임
캐셔
는 주문을 받을 책임
바리스타
는 커피를 제조할 책임을 가지고 있는다.
<br>
좀 더 정의한다면,
개인에게는
어떠한 행동을 할 책임
이 주어지고,
책임에 따른 역할
이 주어진다.
그리고 대화
를 통해 협력
을 하며,
전체적인 커피를 판매하는 과정
을 구성 하고 있다.
<br>
결론은 객체 또한, 이와 다르지 않다는 것이다.
각 객체에게는 어떠한 행동을 할 책임
을 주어지고,
책임에 따른 역할
이 주어진다.
그리고 메세지
를 통해 협력
을 하며,
전체적인 어플리케이션
을 구성하는 것이다.
<br>
실세계는 객체지향을 설명하기에 가장 좋은 예시이다.
따라서 실세계를 통해,
우리는 객체의 다음 특성을 이해 할 수 있다.
여러사람은 동일한 역할을 수행 할 수 있다.
바리스타라는 역할은 한 명 이상이 될 수 있다.
여러 구현체가 있을 수 있다
역할은 대체 가능하다.
A바리스타
가 퇴사하면 B바리스타
가 대신할 수 있다.
구현체는 대체 될 수 있다.
책임을 수행하는 방법을 자율적으로 정한다
커피를 구워삶든, 볶든, 어떻게든 바리스타는 커피를 만들면 된다.
구현체는 자유롭게 구현할 수 있다.
한 사람이 여러 역할을 수행할 수 있다
.
때에 따라서는 캐셔가 바리스타의 역할까지 할 수도 있다.
하나의 구현체는, 여러 인터페이스를 구현 할 수 있다
<br>
추가적으로 실세계를 통해,
우리는 객체세계에서 명심해야하는 내용을 알 수 있다.
객체는 충분히 협력적이어야 함을 명심해야한다.
바리스타
가 협력을 모르는 사람이라면,
혼자 주문을 받고, 커피를 제조하고, 커피를 내주는 독불장군의 스타일은
그 복잡도안에서 자멸해 버릴 것이다.
하나의 객체가 모든 책임을 가지고 있다면, 그 소프트웨어는 복잡도안에서 자멸해버릴 것이다
또한, 객체는 충분히 자율적이어야 한다.
캐셔는 자율적인 방법으로 주문
을 받는다.
바리스타는 자율적인 방법으로 커피
를 제조한다
어떠한 요청을 수신하면, 그 요청을 어떻게 처리해야 하는 것에대해서 객체는 충분히 자율적인 권한을 가지고 있어야한다.
<br>
객체지향이, 실세계를 모방한다고?
앞서의 예시를 보면,
객체지향
이라는 개념이 실세계를 모방하는 것처럼 보일 수있다.
하지만 실세계와 객체지향의 세계
는 명백한 차이점이 존재한다.
객체는 능동적
인 존재가 될 수 있다는 것이다.
객체는 스스로 행동
하는 존재이다.
예를 들어 실세계의 선풍기는 사람
에 의해서,
선풍기의 상태
를 변경 할 것이다.
하지만 객체지향 세계의 선풍기는
선풍기의 스스로 행동
에 의해서
선풍기의 상태
가 변동되는 것이다.
객체지향에세계에서는 우리는 다음과 같이 행동해야한다.
인간 : 안녕 선풍기야? 너 좀 켜져줄래?
public class 선풍기{
private boolean power;
public void on(){
this.power = true;
}
}
<br>
즉, 모든 객체는 의인화
되야 하는 것이다
모든 객체는 자신의 상태를 스스로 행동으로만 변경 할 수 있다.
그렇다면 객체 세계와 현실세계는 전혀 다른 것일까?
그렇지는 않다.
우리는 은유화
라는 기법을 사용한다.
커피라는 실세계를 객체 세계에 Coffee
라는 모델
로 은유로써 정의한다.
은유를 통해서 우리는 객체 세계와 현실 세계에 표현적 차이를 줄이고,
우리는 좀더 직관적으로 객체 세계를 이해 할 수 있는 것이다.
<br>
Coffee라는 모델
강의시간에 책에 있는
커피
라는 실세계의 사물을,
아무 생각 없이Coffee
라는 클래스로 정의했다.
<br>
도메인
은 무엇일까?
소프트웨어는 결국 특정 분야의 문제를 해결하기 위해서 개발된다.
자산관리를 위한 소프트웨어, 커피머신 소프트웨어 등
사용자의 특정 분야
에 필요성을 충족하기 위해
소프트웨어를 개발되고 존재하는 것이다.
여기서 특정 분야를 도메인
이라 정의한다.
모델
은 무엇일까?
모델
은 어떠한 대상을 추상화하고 단순화해서 표현 한 것을 말한다.
둘의 개념을 결합하여,
도메인 모델
은 소프트웨어가 목적하는 특정분야 에서
개념과, 개념과의 관계, 다양한 규칙 등을 주의 깊게 추상화 한 것이다.
하나의 예시를 들면
커피머신소프트웨어를 사용하는 사용자라면
커피머신 소프트웨어를 바라보는 관점
에서
커피
, 머신
과 같은 개념
을 정의하고,
이들간의 관계와 제약 등을 주의 깊게 추상화한것이
커피머신 소프트웨어의 도메인 모델
이 될 것이다.
<br>
중요한 것은 도메인 모델은 이해관계자들이 바라보는 멘탈 모델
이어야 한다 는 것이다.
이해관계자가 생각하는 멘탈모델
,
설계자가 생각하는 디자인 모델
,
그리고 둘 모델로부터의 최종 결과물은 시스템 모델
이라 정의한다.
이해관계자가 생각하는 멘탈 모델
이
설계자가 생각하는 디자인 모델
과
일치 할 수록 좋은 소프트웨어라 할 수 있을 것이다.
그말은 즉, 사용자의 관점이 최대한 반영되었음을 의미하기 때문이다.
<br>
객체지향은 도메인 모델
을 구현 할 수 있는
가장 이상적인 소프트웨어 패러다임이다
객체지향은 은유
를 통해서 모델을 정의한다.
핵심은 은유
를 통해 사용자의 모델과,
소프트웨어의 차이를 최대한 줄일 수 있다는 것이다.
객체지향을 통해 이해관계자와의 관점, 설계자와의 관점을
최대한 일치 시켜 좋은 소프트웨어를 만들 수 있는 것이다.
또한, 사용자의 관점의 모델링은 안정적이다.
소프트웨어의 가장 큰 적은 변경
이다.
그리고 변경은 항시 발생한다.
사용자는 모델에 대한 가장 본질적인
측면을 잘 이해하고 있다.
즉 사용자가 생각하는 모델
이 소프트웨어 반영된다면
그 특성이 오래 유지되고, 변경을 최소화 할 수 있는 것이다.
<br>
왜 책은, 커피를
Coffee
라는 클래스로 정의했을까?실세계의 이해관계자가 바라보는 관점에서의
커피
를
은유를 통해서Coffee
라는 개념으로 정의한다.더불어,
커피머신
을CoffeeMachine
이라는 개념으로도 정의 할 수 있을 것이다.그리고 실세계의
커피
와커피머신
의 관계를
도메인 모델
로 추상화 한다.
그리고도메인 모델
을 이용하여 우리는 구현을 시작한다.개념을 정의하고, 그들간의 관계를 정의한것을
소프트웨어 세계로 가져오는 것이다.
은유를 통해 실세계와 소프트웨어의 세계의 차이를 최소화하며,
이를 통해 사용자 관점을 최대한 반영할 수 있다.특정 문제를 해결하기위해 목적으로하는 소프트웨어가
사용자의 관점이 최대한 반영이 되었다면
좋은 소프트웨어라 정의 할 수 있을 것이다.
<br>
2편에서 계속!