객체 지향....

반박 시 당신 말씀이 맞습니다. 

 

붕어빵에 비유

클래스(붕어빵 틀)는 객체(붕어빵)를 찍어내기 위한 문법입니다. 

• 클래스 : 붕어빵 틀
• 객체 : 붕어빵

 

게임에 비유

게임에는
기사, 마법사, 궁수, 사제 등
클래스(직업, 직능)가 있죠? 

캐릭터를 만들 때,
클래스를 선택한 한 뒤,
이름을 붙입니다. 

이 과정을 거쳐
생성된 캐릭터가
객체입니다.

클래스라는 틀로,
캐릭터라는 객체를
찍어냈다고
할 수도 있죠.  

• 클래스: 기사, 법사, 궁수, 사제, 성기사
• 객체 : 생성된 캐릭터

 

속성과 메서드

객체 지향 프로그래밍에서
핵심은 객체겠죠?

객체란 뭘까요?
속성(데이터)과 함수(동작)를 합친 것입니다. 

* 클래스 내의 함수를 메서드(method)라고 합니다. 

캐릭터를 생성하면,
각각의 캐릭터에
능력치 (헬스, 마나, 근접 공격력, 원거리 공격력 등) 같은
데이터(속성)가 있습니다. 

그리고 캐릭터에는 동작(함수, 메서드)이 있죠. 
공격하기, 방어하기 등등...

둘을 합친 게 객체입니다. 

• 속성: 헬스, 마나, 근접 공격력, 원거리 공격력....
• 메서드: 공격하기, 방어하기, 활쏘기, 돌 던지기 등등

 

왜 이걸 합쳤을까요?
뭔가 장점이 있으니까 합쳤겠죠. 

그 장점을 생각해 보기 전에 
객체 지향 프로그래밍 '이전'의 패러다임인
절차 지향 프로그래밍을 알아 봅시다. 

 

절차적 프로그래밍(procedural programming)

'객체 지향 프로그래밍'과
'절차적(절차 지향) 프로그래밍'은
반대가 아닙니다.

'절차적' 프로그래밍을
한 단계 더 발전 시킨 것이
'객체 지향' 프로그래밍입니다. 

절차적 프로그래밍에서
핵심은 함수(procedure, 프러시져)죠.

이 글에서 
절차적 프로그래밍은 
프러시저 호출을 바탕으로 하는
구조적 프로그래밍을 의미합니다. 

한국어로는
function과 procedure 
둘 다 함수로 변역합니다만,

프로그래밍 기법을 의미할 때는
구분해서 사용합니다. 

procedural programming = 절차적 프로그래밍
functional programming = 함수형 프로그래밍

함수형 프로그래밍도 
상당히 큰 주제입니다. 

가장 간단히 설명한다면
함수(함수(함수(함수(변수))))
스타일의 프로그래밍이라고 할 수 있습니다. 

함수형 프로그래밍은 다음 기회에 ...

from random import sample

print(sorted(sample(range(1, 46), 6)))

 

함수(procedure, 프러시져)와 장점.

함수는 어떻게 만들어졌을까요?
함수 이전엔 GOTO가 있었습니다. 

이 글을 읽는 분 중에
GOTO를 써 본 분은 거의 없으실 겁니다.

물론 저도 못 써봤습니다.

GOTO를 쓰면 가독성이 나빠집니다.

basic

80행에 GOTO 70이 100행에 GOTO 30이 보입니다. 
이런 짧은 코드에서는 읽을만 합니다만...  

그래서 다익스트라 선생님은
구조적 프로그래밍을 하고
goto를 쓰지 말라고 하셨습니다.

물론 GOTO를 잘 쓰면 좋지만
잘 쓰기가 쉽지 않죠.

명령을 합쳐서
함수를 만들고
GOTO를 없앤 것이
절차 지향 프로그래밍입니다. 

명령들을
프러시저(함수)로 모으니까
어떤 장점이 생기던가요?

코드의 읽기가 쉬워지고,
코드의 재사용이 쉬워지고,
(구조적이라 컴파일 시 최적화가 잘 된다.)

 

객체 지향의 장점은 뭘까?

절차적 프로그래밍에서
한 단계 더 발전해서
동작(함수)과 데이터(속성)를 합치면
어떤 장점이 생길까요?

 

캐릭터 생성하기

위에서.... 
게임 캐릭터 만들기가 편해졌잖아요. ㅋ

직업 클래스 몇 개 만들어서 
캐릭터 객체 빠바방 찍으면 되잖아요. 

 

만들어진 캐릭터 (객체) 단위로 데이터가 관리됩니다. 
a 캐릭터와 b 캐릭터의 헬스는 별도로 관리되죠. 
둘이 만나서 싸우지 않는 이상,
직접 관계되는 일은 없습니다. 

특별한 절차 없이는
외부에서 이 값을 건드리지 못하게 만들기도 합니다. 
이를 캡슐화라고 합니다. 

 

계산기, 웹 브라우저 그리고 GUI

조금 더 프로그래밍스러운(?) 예를 들어 보겠습니다.

GUI(그래픽 유저 인터페이스)에서 작동하는
계산기를 생각해봅시다. 

각각의 계산기엔
동작(함수, 프로시져)과
데이터(속성)가 있습니다. 

• 동작: 더하기, 빼기, 곱하기, 나누기 등
• 데이터: 계산 결과, 계산 과정 로그 등

 

이렇게
(프로그래밍에 필요한)
동작과 속성을 찾아내는 것을
객체 지향에서는
'추상화'라고 합니다.

GUI에서
계산기 버튼의 재질까지
코드로 옮길 필요는 없는 거죠.
하지만 VR이라면...

추상화한 데이터와 동작을 합쳐서
계산기 객체로 정의할 수 있습니다. 

 

객체 지향을 사용하면,
현실의 어떤 사물(객체)을
프로그래밍으로 구현하기가
편리해집니다. 

 

계산기 2개를 GUI로 띄울 때, 
계산기 클래스를 만들어서,
계산기 객체를 2번 만들면
아주 편하겠죠?

 

웹 브라우저 창을
여러 개 띄우는 것도
마찬가지입니다.

 

GUI 관련 기술을 이끌었던 앨런 케이 역시 대표적인 인물이다.
오늘날 대부분의 GUI의 기초가 된 제록스 알토를 개발했으며,
객체 지향 프로그래밍의 개념을 다지고
객체 지향 개발 언어 스몰토크(Smalltalk)를 만들었다.
https://it.donga.com/22351/

 

실제로
(최초에 가까운) 객체지향 언어, 스몰토크의 개발자 
앨런 케이 선생님은 GUI에서도 선구자셨어요. 

스몰토크

 

엘런 케이 선생님이 GUI를 쉽게 만드려고 객체지향을 만들었네.
계산기 여러 개 띄우려고 이 걸 만드신 건가...
라고 생각해도 거의 맞을 겁니다.

 

객체지향 프로그램이
어렵게만 느껴지시겠지만, 
프로그램의 복잡도가 증가하거나
소스가 길어지면
객체지향이 유리합니다. 

 

일반인용, 공학용, 프로그래머용
계산기 3개를 만든다면... 
3개의 공통점을 찾아서
base 클래스를 만든 뒤
base 클래스를 상속받아
서로 다른 부분만 코딩하면 되겠죠?

이렇게 공통점 묶기를 안 했다면, 
계산기 코드에서
공통적인 부분이 3곳 존재하며,
이를 수정할 때
3번의 찾기와 바꾸기가
발생합니다. 

여러분들은 잘하시겠지만,
저는 이 정도의 유지보수에도
실수를 한 적이 꽤 있습니다. 

혹시 이게 공감이 안된다면
수십 개 정도의 공통부분이 있는데
여기의 기능 개선이 필요하다고
생각해 보십시오. 

 

제대로 객체지향을 사용하면
유지보수가 쉬워집니다. 

 

코딩 시작한 지 얼마 안 되었을 때는
간단한 코딩만 하기 때문에 
객체 지향을 왜 쓰는 건지 이해하기 어렵습니다. 

그게 당연합니다. 

절차 지향 프로그래밍 만으로도
프로그램을 만들 수 있죠. 

객체 지향 개념이 없었을 때도
프로그래밍은 있었어요. 
뭐 따지자면
절차 지향 개념이 없었을 때도
프로그래밍은 있었습니다만... 

 

부족한 글 읽어주셔서 감사합니다. 
반박 시 당신이 맞습니다. 

 

객체 지향은 꽤 큰 개념입니다.

그 중에
비기너도 바로 이해할 수 있는 만한 부분을 재료로 
글을 써 보았습니다.

생물학 전공이었던 엘런 케이는
세포에서 영감을 얻었다고 합니다.

각각의 객체는 메세지를 주고받고, 데이터를 처리할 수 있다.
객체의 협업으로 프로그램이 구성된다. 

그리고 엘런 케이는 네이밍을 잘못한 것 같다고도 했습니다.
객체 지향이라는 이름을 쓰다보니, 객체나 클래스에 초점이 가게 된다.
OOP의 본질을 흐리는 것 같다. 진짜 핵심은 '메시징'이다.

하지만 비기너에게 이렇게 설명하기는 쉽지 않더군요. 

추상화, 공통점 묶기, 캡슐화, 상속 정도의 개념에서 시작해서
점점 이해를 넓히는 것이 좋을 것 같습니다.