thumbnail

객체지향의 사실과 오해

서론

<img src="https://file.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://file.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://file.podo-dev.com/blogs/images/2020/01/10/origin/7c8096f6-18b8-49cf-b3bf-279064d1d790.png" alt="base64.png" style="width:240px;">

  1. 손님 : 따듯한 아메리카노 한잔주세요!
  2. 캐셔 : 네 주문받았습니다, 바리스타님 따아 하나요!
  3. 바리스타 : 넵, 따아 만들게요 ~ 따아 나왔습니다!
  4. 캐셔 : 손님, 따듯한 아메리카노 나왔습니다.
  5. 손님 : 감사합니당.

<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편에서 계속!

CommentCount 0
이전 댓글 보기
등록
TOP