016. OOP 추상화 = 모델링

지난 시간 추상화라는 단어의 일반적인 뜻을 알아봤습니다.

 

추상화란 구체적인 것을 분해해서 관찰자가 관심있는 특성만을 가지고 재조합하는 것이라고 정리할 수 있습니다.

 

이렇게 정리되시지 않았다구요.  그건 제 잘못입니다. 설명을 제대로 못한 것이죠. ^^

일단 위의 개념을 머리 속에 두시고 OOP 의 추상화로 이야기를 전개해 보도록 하겠습니다.

 

객체지향의 4대 특성은 무엇을 통해 구현 될까요?

네 바로 클래스를 통해 구현 됩니다.  또는 객체라고 할 수도 있겠구요.

 

그런데 여기서 클래스와 객체에 대해서 이야기를 하고 넘어가야 할 듯 합니다.

붕어빵틀 vs 붕어빵은 지금 이 순간부터 버리십시요.

버리셨죠.. ^^

 

그럼 먼저 클래스가 뭔지, 객체가 뭔지 이해하기 위해 질문부터 던져보겠습니다.

 

쥐는 클래스일까요? 객체일까요?

미키마우스는 클래스일까요? 객체일까요?

뽀로로는 클래스일까요? 객체일까요?

펭귄은 클래스일까요? 객체일까요?

 

정답은 역시 아래를 마우스로 드래그 하시면 보이실 겁니다. 하지만 드래그 전에 먼저 각 문제당 최소 30초씩은 고민해 보시길...

 

쥐는 클래스, 미키마우스는 객체, 뽀로로는 객체, 펭귄은 클래스

 

4개 모두 정답을 맞추셨나요?

못 맞추셨다고요? 좌절하거나 낙망하지 마십시요.  기존의 객체지향의 추상화를 배우실 때 위의 4가지를 클래스인지 객체인지 구분하는 방법조차 가르침을 받은 적 없으시니 오히려 맞추신 분이 대단한 겁니다.

 

그럼 여기서 간단하게 클래스와 객체를 구분하는 방법을 가르쳐 드리죠.

 

쥐의 나이는 몇 살일까요?

미키마우스의 나이는 몇 살일까요?

뽀로로의 나이는?

펭귄의 나이는?

 

이런 질문에 딱 답이 나온다면 그건 객체입니다.  답 하시기에 불편하시다면 그건 클래스입니다.

 

질문 자체가 안 어울리는 존재에 대해서는 생산년도, 또는 색상 등등 다른 유사한 질문을 해보시고 답이 있는가 없는가를 판단하시면 됩니다.

 

쉽죠? ^^

 

그럼 여기서 클래스를 설명.. 아니 먼저 객체를 설명해 보도록 하겠습니다. 왜냐하면 클래스는 실존 개념이 아니기 때문에 객체부터 설명하는 것이 쉽습니다.

 

일단 사전적 용어로 객체 알아보겠습니다.

그런데 나벨(Naver: 독일식 발음입니다.) 국어사전에서 찾으니 이건 제가 설명드릴 객체가 아니네요. ^^

사실 지금은 OOP 를 객체지향이라고 부르지만 예전에는 개체지향이라는 말로 쓰기도 했습니다.

만약 제게 투표권이 있었다면 객체지향이 아닌 개체지향이라고 했을텐데.. 아쉽네요.

 

Object 를 영어사전에서 찾아 보시면

 

object 명사
1. 물건, 물체   2. 욕망, 연구, 관심 등의 대상   3. 목적, 목표

 

결국 객체보다는 개체라는 뜻이 더 맞습니다.

 

앞으로 OOP 를 객체지향이 아닌 개체치향으로 번역하시길...'

저는 대세를 따라 그냥 객체지향으로.. ^^v

 

그래서 개체를 나벨 국어사전에서 찾아봤습니다.

 

개체(個體)
명사
1. 전체나 집단에 상대하여 하나하나의 낱개를 이르는 말.
2. <생물> 하나의 독립된 생물체. 살아가는 데에 필요한 독립적인 기능을 갖고 있다.
3. <철학> 단일하고 독립적인 통일적 존재. 철학 사상의 발전 과정에서 이 통일성은 물질적ㆍ양적 측면, 또는 정신적ㆍ질적 측면 따위의 여러 관점에서 고찰되었다.

 

음 이 표현도 조금 맘에 안 드네요.  그래서 OOP 의 객체를 설명 드리기 위해 제가 다른 설명을 붙여 보겠습니다.

 

객체: 세상에 존재하는 유일무이한 사물

 

또 이러한 객체는 생명체이건 무생물체(의인화 가능하겠죠)이건 속성들과 기능들을 가지고 있게됩니다.

 

이에 대비되는 클래스의 정의를 내려볼까요

 

클래스: 집합. 같은 속성들과 기능들을 가진 객체들을 총칭하는 개념

 

어려우신가요?  그럼 아래 공식만 기억해 주세요.

 

클래스 : 객체 = 쥐 : 미키마우스 = 펭귄 : 뽀로로 = 사람 : 김연아

 

또는 벤다이그램으로 표기해 봐도 좋겠군요.

 

자 수많은 객체들이 보이는군요.

 

그리고 그 객체들의 특성(속성들 + 기능들)을 뽑아보니 객체들을 통칭할 수 있는 집합적 개념이 나오는군요.

 

이제 클래스 vs 객체의 개념이 좀 서시나요?

 

객체는 세상에 유일무이(unique)한 사물이다.

 

클래스는 여러개의 객체들을 총징하는 집합의 개념이다.

 

이래도 이해 못 하시면... ㅡㅡ;

 

이러하니 저기 객체 중에 하나를 뽑아 나이를 물어보도록 하죠.

 

한효주 나이는? 모르신다구요? 나벨 검색하시면 금방 답이 나옵니다.

장동건 나이는? 나벨 검색하시면 금방 답이 나옵니다.

사람 나이는?  이건 답이 안 나오죠. 나벨도 구골도 답이 없습니다.

 

여기서 용어 좀 정리하겠습니다.

 

자 새로운 사람이 태어났다고 하죠.  이걸 객체지향언어인 Java 로 표현하면 어떻게 될까요?

아 이름도 지어줘야겠죠.  이름은 뭐라할까나.. 흠흠... 홍길동이라고 해보죠.

 

사람 홍길동 = new 사람();

 

또 새로운 사람이 태어났습니다.  이번에 이름을 줄리엣이라고 해볼까요.

 

사람 줄리엣 = new 사람();

자자 무슨 일이 일어난 거죠.  사람이라는 클래스를 이용해서 새로운 유일무이한 하나의 사람(객체)을 만들어 홍길동(객체참조변수)이라는 이름을 지어주었네요.

전문용어 나오기 시작했습니다.  이왕 나온 전문 용어이니 조금 더 파 보겠습니다.

 

클래스 영어로 Class

객체는 영어로 Object

그런데 Class 를 이용해 Object 를 만들었다는 것을 강조할 때는 Object 라는 표현 말고도 Instance 라는 표현을 씁니다.

 

객체 = Object = Class 의 Instance

 

클래스를 객체의 설계도라고 하는 말은 바로 이런 과정에서 나왔다고 보시면 됩니다.

 

우리는 실제로는 객체들을 인식하고 그 다음에 클래스를 인식하게 됩니다.

 

하지만 하나님은 객체들을 만드시기 전에 클래스라는 개념을 먼저 갖고 계셨겠죠.

무슨 말이냐 하면 아담과 이브라는 객체를 만드시기 전에 클래스로서 사람이라는 개념을 먼저 가지고 계셨을 거라는 겁니다.

 

그런데 컴퓨터 프로그램을 만드는 과정에서 개발자는 바로 해당 어플리케이션의 창조자가 됩니다.

(제가 프로그래밍을 좋아하는 이유입니다. ^^)

 

그래서 우리도 객체지향프로그래밍을 함에 있어서 먼저 클래스를 설계하게 됩니다.

 

그런데 이게 OOP 추상화와 무슨 관련이 있나고요?

이제부터 관련을 찾아보도록 하겠습니다. 급하시긴.. ^^

 

자 이제 사람이라는 클래스를 설계한다고 해보죠.

사람 클래스를 만들기 위해 사람에서 시작하는 것이 아니라 주변에서 보이는 사람 객체들을 가지고서 사람 객체들이 가진 공통된 특성을 찾아봅시다.

 

시력, 몸무게, 혈액형, 키, 나이, 직업, 취미.... 이렇게 명사나 형용사로 표현되는 특성들을 속성이라고 합니다.

먹다, 자다, 일하다, 침뱄다, 운전하다, 울다... 이렇게 동사로 표현되는 특성들을 기능/행위라고 합니다.

 

여기까지 작성하다가 블루스크린.. ㅡㅜ 그만 쓰라는 뜻인듯...

옷~~빵도 없고.. 고로 이만... 휘리릭...

하려했으나 임시저장의 힘으로 다시...

 

자 그럼 사람 클래스를 만들어 보겠습니다.  갑자기 UML Class 다이어그램을 그리고 싶어지지 않으시나요?  그리고 싶으실꺼예요.

^^

 

사람의 모든 특성을 쭈욱 나열해 보고 싶었지만.. 일단 이 정도로..

그런데 사람 클래스가 사람의 모든 특성을 나열할 수 있을까요? 그럴 필요가 있을까요?

 

여기서 또 하나의 개념이 들어옵니다.  바로 어플리케이션 경계입니다.

 

어플리케이션 경계을 알기 위해서는 단순한 질문 하나에서 시작합니다.

 

"내가 창조하려는 세상은 어떠한 세상인가?"

 

조금 프로그래밍적으로 질문을 바꾼다면

 

"내가 만들고자 하는 어플리케이션은 어디에서 사용되어질 것인가?"

 

되겠습니다.

 

만약 병원 어플리케이션을 만들고 있다면 사람은 곧 환자를 의미하는 좀더 구체적인 이름으로 바꿀 수 있을 것이고 클래스 설계도 달라질 겁니다.  은행 어플리케이션을 만들고 있다면 사람은 곧 고객 이라는 구체적인 이름으로 바꿀 수 있을 것이고 클래스 설계도 역시 달라야 합니다.

어플리케이션 경계에 따라 사람 클래스 설계가 어떻게 달라지는지 아래 그림으로 비교해 보았습니다.

 

 

병원 어플리케이션	은행 어플리케이션
사람은 곧 환자다.	사람은 곧 고객이다.

 

병원 어플리케이션이다라고 생각하니 사람 클래스에서 필요없는 특성들이 보이기 시작합니다. 역시 어플리케이션 경계를 은행이라고 생각하니 필요없는 특성들이 나오기 시작합니다.

 

자 이제 추상화의 일반적인 뜻을 다시 새겨 보죠.

 

추상화란 구체적인 것을 분해해서 관심 영역에 대한 특성만을 가지고 재조합하는 것

 

이제 이 정의를 조금 더 프로그램적으로 표현해 보자면

 

추상화란 구체적인 것을 분해해서 관심 영역(어플리케이션 경계, Application Boundary)에 있는 특성만을 가지고 재조합하는 것 = 모델링

 

모델링이라는 말에 동의?

 

지구본을 보시죠. 지구를 정확히 표현하나요? 지구의 굴곡과 바다, 기후를 지구본에 다 표현할 수도 없으며 그럴 필요도 없습니다.

지구본은 지구를 모델링했다는 것에는 동의 하시죠.

과학박물관에 있는 태양계 모델을 생각해 보죠.  태양계를 정확히 묘사하나요?  다른 건 두고서라도 태양을 축구공 크기로 표현한다면 수성은 축구장 넓이 만큼 지난 지점에 쌀 한톨 놓는 정도로 표현해야 할 겁니다.

 

모델은 실제 사물을 정확히 복제하는 게 아니라 목적에 맞게 그 특성만을 캐치해서 표현하는 것입니다.

 

바로 모델은 추상화를 통해 실제 사물을 단순하게 묘사하는 것이죠.

 

이런 모델링(추상화)은 OOP 에서 클래스를 설계할 때 필요한 기법이고 또한 데이타베이스의 테이블을 설계할 때 필요한 능력입니다.

 

어떻게 모델링(추상화)을 하느냐가 얼마나 중요한지는 실무 경력이 조금이라도 있다면 아실거라 봅니다.

 

이제 "OOP 4대 특성에서 추상화는 모델링이다" 라는 말에 동의가 되시나요.

 

무척 길어졌습니다.  두 시간에 걸쳐 작성했네요. ^^

이 내용을 칠판을 이용해서 구두로 설명하면 하면 30분도 안 되는 내용인데 말이죠.. ㅡㅡ;

그리고 무척 중요한 실습은 또 해볼수 없다는 문제도 있네요.

 

저를 찾아오세요. 시간 내어 설명해 드립니다.

오실 때는 마음은 가볍게 지갑은???
오셨는데 객체지향 설명 다 듣고도 시간이 남는다.

그럼 RDB 초급 이야기도 들으시면 되죠. ^^

RDB 초급 맛 보기 "CAD 수업은 두시(DUSI)다." + 클래스 설계 하실 줄 알면 테이블 설계는 이미.. 클래스에서 기능/행위 부분을 빼면 DB 테이블이 됩니다.

 

음~ 추상화를 이런 식으로 설명한 책이나 강좌를 보신 적이 없다구요.

네 없습니다. ^^

그게 바로 추상화를 배운 것 같음에도 클래스와 객체를 구분조차 하지 못한 이유이며, 클래스를 설계하라고 할 때 먹먹해 지고, 남이 만들어 놓은 클래스 설계를 보면서 딱히 꼬집지는 못했지만 욕하게 되는 이유입니다.  또한 모델링의 개념을 몰랐기에 클래스를 적정하게 설계하고 분할하는 방법도 몰랐던 거죠.

그럼 이걸 알고 있는 저는 클래스 설계 잘 하냐구요?  이거 왜 이러세요.

한국에서 개발자에게 클래스 설계 잘할 시간 주는 회사 많지 않습니다. ㅡㅡ;

 

중요한 부분만 다시 강조.

 

OOP 의 추상화는 모델링이다.

클래스 vs 객체 = 펭귄 vs 뽀로로

클래스 설계에서 추상화가 사용된다.

클래스 설계를 위해서는 어플리케이션 경계부터 정하라.

 

다음 강좌는 드디어 스프링에서 말하는 추상화???

택도 없습니다.. ^^

상속 과정에서의 추상화, 구체화

인터페이스의 추상화

다형성의 추상화

등등을 설명해야 하는데..

저거 다 설명하고 살 좀 붙이고 정리 좀 하면 제가 쓰고자 하는 책이 되어 버리네요.

그리하여 어쩌면 바로 스프링 추상화로 갈지도.. ㅡㅡ;  강좌 쓰는 시간 모으면 책을 쓸 시간이 나올지도.. ㅡㅡ;

뭐 어째건 다음 강좌는 그때 그때 달라요.. ^^ 특히 추상화는 딱히 제목을 정하고 시작 것도 아니라서...

 

이 내용에 대한 많은 덧글 부탁드립니다.

특히 다른 곳에서 이렇게 추상화, 클래스 vs 객체를 설명하는 것을 보거나 들으셨다거나, "나는 이미 알고 있었다", "나는 다르게 생각한다" 등등...

 

아 이제 날짜도 변경되었네요.

 

"엘리 엘리 라마 사박다니" 외치신 예수님을 찬양하며 마무리 합니다.

추가 - 2013년 03월 13일

개똥벌레님이 아주 좋은 질문을 주셔서 제가 책에 쓸 내용을 스포일링(?)하게 되었네요. ^^;

개똥벌레님 허락 없이 질문과 저의 답변을 끌어올려 봅니다.(개똥벌레님 링크도 없고 익명이니 반항 안 하실 거죠. ^^/)

질의 하신 내용입니다.

개똥벌레 2013/03/13 16:52     

자바의 XX  저자 XXXX씨같은 경우도 붕어빵- 붕어빵틀을 인용하고 있는데요. 붕어빵틀은 클래스지만, 구어져 나온 붕어빵은 Instance의 개념이 맞지 않나요?? 똑같은 틀에서 만들어졌지만 빵 하나하나는 별개의 존재라고 이해했는데.. 광의적인 "붕어빵"이 아니고, 빵 1개. 이걸 뜻하는 거라면요

답변 드린 내용입니다.

BlogIcon 여름나라겨울이야기 2013/03/13 17:48   

제가 이야기 하는 건.. 장님 코끼리 만지기라는.. ^^

장님이 코끼리 꼬리만 만지고 오면 코끼리를 "털 달린 뱀" 같다고 이야기 하겠죠. 그럼 이 장님의 표현은 맞는 걸까요? 틀린 걸까요?

클래스 vs 객체를 붕어빵틀 vs 붕어빵 이라고만 하는 것은 일면이라는 거죠. 말씀하신 것처럼 클래스의 인스턴스가 객체다라고 하는 건데.. 개발자들이 그게 클래스 vs 객체의 전체라고 이해하고 있다는 게 문제지요. 그렇기에 단어가 하나 주어졌을때 객체인지 클래스인지 구분을 못하는 것이구요. 그렇게 일부만 알고 만들어진 객체지향시스템들은 논리가 잘 안 서게 되는 것이구요.

간단한 퀴즈 하나 드리죠. 다수의 붕어빵틀을 생산하는 기계가 있다고 하죠. 그럼 기계는 클래스이고, 붕어빵틀은 객체일까요? 이것에 대해 명확히 답을 하실 수 있다면 객체지향의 추상화를 이해하고 계신 겁니다. 답이 명확하지 않다면.. ^^;

기계가 붕어빵틀들을 만들어 내니 둘 사이에 클래스와 객체 개념을 세울 수 있나요?

클래스 객체명 = new 클래스(); // OK!!!
붕어빵틀 붕어빵_1 = new 붕어빵틀(); // OK???
기계 붕어빵틀_1 = new 기계(); // OK??????????

이런 논리로 만들면 인간적 사고로 코딩하자던 객체지향은 멘붕 속으로.. ^^;

붕어빵 붕어빵_1 = new 붕어빵() // OK!!!
붕어빵틀 붕어빵틀_1 = new 붕어빵틀() // OK!!!

제가 이야기하는 점을 이해하셨길...

붕어빵틀 vs 붕어빵 = 클래스 vs 객체 논리가 얼마나 위험한 것인 줄 아시겠죠. 이렇게 가르치고 배우니 객체지향 이해하는데 3년 이상 걸린다 하고 3년 이상 걸려서 이해하는게 아니라 그냥 암기/내재화/당연시 하게 된거죠.

결론 머리 속에 그려지는 붕어빵틀도 클래스요, 붕어빵도 클래스입니다. 그런데 지금 내가 보고 있는(나가서 보세요. ^^) 저 붕어빵틀, 저 한마리 붕어빵은 객체입니다.

더 깊이 이야기하자면 붕어빵틀은 붕어빵에 대한 팩토리 정도 아닐까요? ^^

다시 강조 드립니다. 

- 클래스는 실체가 아니라 개념입니다. 

- 객체는 실체입니다. 

- 클래스와 객체 사이에는 집합과 원소라는 아주 간단한 논리가 필요합니다.

위 내용을 머리에 안 가지고 계시면 객체지향이 인간지향적이다라는 말은 어불성설이 되고, 객체지향 어렵다는 잘못된 험담만 하게 됩니다.  객체지향은 컴퓨터 지향적 사고에서 벗어나 인간 지향적 사고로 프로그래밍을 만들고자 하는 사조입니다.  제대로 알고 이해하면 객체지향 어렵지 않아요. ^^;

제가 스포일링 했지만 저의 책 나오면 다 사주실 거죠. ㅡㅡ;

그리고 Spring 강좌인데 왜 객체지향 추상화에 댓글이 두 번째로 많을까요. ㅡㅡ;
이게 현실인 건가요. ㅡㅡ;