클래스 vs 객체 = 붕어빵틀 vs 붕어빵?

붕어빵과 붕어빵틀

처음 Java를 접하게 될 경우 객체와 클래스에 관해 설명을 위와같이 들어본 사람이 아마 대다수 일 것이다. 하지만 이것은 쉽게 설명하려고 하다보니 생긴 오류다. 개발을 할 때 이러한 부분을 정확하게 선 긋고 확실한 개념으로 일하고 싶기에 이 부분의 오해를 풀어보려한다.

클래스 객체명 = new 클래스();

일반적으로 위와 같이 클래스로 객체를 생성하는 방식이다. 이를 붕어빵과 붕어빵틀로 바꿔 비유해보겠다.

붕어빵틀 붕어빵 = new 붕어빵틀();

이 부분이 아직 잘 이해가 안간다면 붕어빵틀을 생산하는 금형기계가 있다고 해보자. 그럼 붕어빵틀이 붕어빵을 찍어내서 클래스라고 한다면 같은 논리로 금형 기계는 붕어빵틀을 찍어내는 클래스가 된다. 이를 코드로 나타내면 다음과 같다.

금형기계 붕어빵틀 = new 금형기계();

위 코드를 인간적인 말로 번역해보자면

'새로운 금형기계를 하나 만들었더니 붕어빵틀이 되었다' 라는 말이 된다.

이해가 안 되는 예제다. 절대 금형기계와 붕어빵틀이 클래스와 객체 관계가 아닌듯

붕어빵틀과 붕어빵도 클래스와 객체 관계가 아니다.

 

그렇다면 붕어빵에게 붕어빵틀은 무엇일까??

붕어빵을 만드는 팩터리였던 것이다. 팩터리란 디자인 패턴에 나오는 팩터리 디자인 패턴을 말한다.

 

진도를 더 나아가 다음 문제들의 답을 생각해보자.

• 사람은 클래스인가? 객체인가?
• 김연아는 클래스인가? 객체인가?
• 뽀로로는 클래스인가? 객체인가?
• 펭권은 클래스인가? 객체인가?

클래스와 객체를 구분하는 간단한 방법은 나이를 물어보는 것이다.

김연아의 나이? 사람의 나이? 여기서 나이가 있는것이 객체이고 나이를 물을 수 없는 것은 클래스가 된다.

그렇기 때문에 클래스는 분류에 대한 개념이지 실체가 아니다.

객체는 실체다.

추상화: 모델링

추상화란 구체적인 것을 분해해서 관찰자가 관심 있는 특성만 가지고 재조합하는 것이라고 정리할 수 있다. 이 개념을 가지고 객체지향의 추상화로 이야기를 전개해 보자.

 

클래스를 설명하기 전에 먼저 객체를 알아보자. 왜냐하면 클래스는 실존하는 것이 아니기 때문에 실존하는 객체부터 이해하는 것이 쉽다.

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

또 이러한 객체는 생물이건 무생물이건 속성과 기능을 가지고 있다고 볼 수 있다. 무생물인 경우는 의인화해서 생각해보면 속성과 기능을 가지고 있다는 말을 이해하기 쉬울 것이다. 이에 대비되는 클래스의 정의를 알아보자.

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

클래스의 개념이 어렵다면 이전에도 나왔던 다음의 공식만이라도 기억하자.

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

세상에 존재하는 유일무이한 객체를 특성(속성+기능)에 따라 분류해보니 객체를 통칭할 수 있는 집합적 개념, 즉 클래스다.

• 객체는 유일무이한 사물이다.
• 클래스는 같은 특성을 지닌 여러 객체를 총칭하는 집합의 개념이다.

클래스를 반, 학급과 같은 뜻으로 기억하는 사람들이 많을텐데, 사실 가장 많이 사용되는 의미는 분류다. 따라서 객체들을 특성에 따라 분류했다는 의미가 된다.

 

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

 

또 새로운 사람이 태어났는데 이번에는 이름이 줄리엣이라고 해보자.

 

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

 

사람이라는 클래스(분류)를 이용해 유일무이하고 새로운 하나의 사람(객체)을 만들어 홍길동(객체 참조 변수)이라는 이름을 지어준 것이다. 그런데 클래스를 이용해 object를 만들었다는 것을 강조할 때는 object라는 표현보다는 클래스의 인스턴스(instance)라는 표현을 쓴다.

 

객체(object) = 클래스의 인스턴스

 

클래스를 객체의 설계도라고 설명하는 말은 바로 이런 과정에서 나왔다고 보면된다. 붕어빵과 붕어빵틀도 클래스와 객체의 이런 일면만 설명하는 메타포인데, 그걸 클래스와 객체 관계의 관계를 전부 표현하는 메타포로 착각하면서 지금까지도 그 폐해가 계속되는 것이다.

 

인간은 객체를 먼저 인식하고 그 다음에 클래스를 인식하게 되지만 창조주인 하나님께서는 객체를 만드시기전에 클래스라는 개념을 먼저 갖고 계셨을 것이다.

아담과 이브라는 객체를 만드시기 전에 클래스로서 사람이라는 개념을 먼저 가지고 계셨을 것이다.

 

컴퓨터 프로그램을 만드는 과정에서 개발자는 바로 해당 애플리케이션의 창조자가 된다. 그래서 우리도 객체 지향 프로그래밍을 할 때 클래스를 먼저 설계 하게 된다. 그런데 이게 객체 지향의 추상화와 무슨 관련이 있을까? 사람이라는 클래스를 설계 한다고 해보자. 사람 클래스를 만들기 위해 주변에서 보이는 실체들,

즉 사람 객체들을 관찰해서 사람 객체들이 가진 공통된 특성을 찾게 된다.

 

시력, 몸무게, 혈액형, 직업, 연봉, 자동차 유무 등등 무수한 속성을 갖게 되며,

먹다, 자다, 일하다, 노래듣다 등 무수한 기능/행위를 갖는다.

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

 

여기서 또 하나의 개념이 나온다. 바로 애플리케이션 경계다.

때로는 애플리케이션 경계를 컨텍스트(Context)라고 부르기도 한다.

애플리케이션 경계를 알기 위해서는 단순한 질문 하나만 던져 보면 된다.

 

"내가 창조하려는 세계는 어떤 세상인가?"

 

조금 더 프로그래밍적으로 질문을 바꾼다면 다음과 같이 바꿀 수 있을 것이다.

 

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

 

만약 병원 애플리케이션을 만들고 있다면 사람은 환자를 의미하는 좀 더 구체적인 이름으로 바꿀 수 있을 것이고 클래스 설계도 달라질 것이다. 병원 애플리케이션이라고 생각하니 사람 클래스에서 필요 없는 특성들이 보이기 시작한다.

 

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

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

 

출처 : https://wikibook.co.kr/java-oop-for-spring/

스프링 입문을 위한 자바 객체 지향의 원리와 이해