하나하나씩 뜯어보면서 알아보자

위의 사진을 보자. 먼저 절차지향을 보면 순서대로 프로그램을 실행하는 프로그램임이 틀림없습니다.

그 다음으로 눈길이가는 객체지향을 확인해봅시다.

개별적으로 자주 참조되거나 호출되는 변수들을 분리하는

함수들을 '객체'라는 틀로 묶어서 사용했다는 것은 둘째 치고,

순서대로 차근차근 진행되는 실행방식에 있어서는 차이점이 없는 것 같습니다.

문제점을 짚어보자 🔎

평소에 우리는 객체지향에 대해 알아보려면 어떻게 하나요?

네 맞습니다. 절차지향 방식이랑 비교를 합니다. (마치 꼬리표처럼 말이죠.)➰

하지만 이상하지 않나요? 왜 객체지향을 공부할때는 항상 절차지향과 비교를 하는건가요?

객체지향은 코드가 절차에 따르지않고 동시다발적 혹은 순서가 없다는말이 될까요?

정확히 다시 알아보자 👀

우선 두개의 방식 모두 순서대로 차근차근 진행되는 실행방식에 있어서는 차이점이 없는 것 같습니다.

그렇다면 왜! 대체 짝꿍처럼 객체지향에 대해 알아보려면 굳이 "절차"지향과 비교하는것일까요?

사실 객체지향의 개념과 특징을 설명함에 있어서 굳이 절차지향과 비교할 필요는 없습니다.

객체 란 기존의 방식인 변수 따로, 함수 따로의 분산적이고 통일성 없는 추상화 과정을 통합하여 표현 대상(문제 해결 대상)을 좀 더 모듈화 하기 쉽게 도와주는 도구에 불과하고

객체지향 프로그래밍은 객체의 디자인을 한 뒤에 이들의 데이터 플로우를 짜고 진행 시나리오를 설계해나가는 방식의 개발 방법론일 뿐이기 때문입니다.

플로우차트를 먼저짜느냐 데이터 모델링을 먼저 하느냐의 차이 지 그 이후로는 절차지향 프로그램이나 객체지향 프로그램이나 다들 정해진 알고리즘을 따라 순서대로 실행되는 건 마찬가지 입니다.

사실 절차지향이라는 말이 햇깔리게 만드는 주범이 아닐까요? 😅

굳이 "절차지향"이라는 이름을 써야 한다면

"절차지향 프로그래밍은 프로그램의 순서와 흐름을 먼저 세우고 필요한 자료구조와 함수들을 설계하는 방식이고, 객체지향 프로그래밍은 반대로 자료구조와 이를 중심으로 한 모듈들을 먼저 설계한 다음에 이들의 실행 순서와 흐름을 짜는 방식이다"

정도의 설명을 추가하는 것만으로도 그렇게까지 헷갈릴 일은 없을 것입니다. 그게 아니면,

절차지향이라는 이름 대신 차라리 "비 객체지향 방식"이라고 쓰는 게 나을지도 모릅니다.

알기 쉽도록! 🙋

당신이 다음과 같은 레고성을 만들고 싶을 때 만드는 유형을 2가지로 나눌 수 있는데,

- 설명서를 보고 레고 블록을 그때그때 그 순서에 맞게 조립하는 방법

- 성을 조립할 레고블록을 성의 머리부분, 성의 다리부분, 성의 내부부분을

  각 파트별로 미리조립 후 필요할 때 조립하는 방법

와 같이 두 방법이 있는것이죠. 😁

착각 바로잡기 📿

앞서 살펴본 자판기 프로그램 예시에서도 볼 수 있듯이, 여러 책에서는 절차지향과 객체지향을
비교할 때 대부분이 절차지향은 "순서도" 로, 객체지향은 "클래스 다이어그램" 으로 도표를 그려서 비교해놔서 혼란을 가중시킵니다.

애당초 순서도와 클래스 다이어그램은 서로 용도부터 다른 도구입니다.

알다시피 순서도는 알고리즘을 표현하기 위한 도구이고,

클래스 다이어그램은 자료구조 간의 상호관계를 기술하기 위한 도구입니다.

객체지향 방식으로 설계하더라도 그 알고리즘을 표현할 때 당연히 순서도를 활용할 수 있으며, 반대로 절차식 방식으로 설계하더라도 클래스 다이어그램을 이용하여 데이터들과 모듈 간의 관계를 설명할 수 있습니다.

물론 확실히 절차식 프로그래밍에서는 거의 순서도 위주로,

반대로 객체지향 프로그래밍에서는 *UML 위주로 설계가 이루어지는 것은 엄연한 사실입니다.

그러나 클래스 다이어그램의 개념과 용도에 익숙하지 않은 상태에서 저 그림만 본다면 객체지향 프로그램은 모듈들이 실시간으로 정보를 주고받고, 순서에 상관없이 동시다발적으로 실행된다 는 착각을 심어줄 수 도 있습니다.

UML 이 대체 뭔데?

쉽게 말하자면 시스템의 정적인 상태인 '논리적인 구조'를 표현합니다.

클래스간의 관계를 한눈에 파악하는게 주 목적입니다.

결론 🔨

객체지향은 기존의 방식에 비해 프로그램의 수행절차를 간소화해주지만, 절차를 무시하는 것은 결코 아닙니다.

깔끔한 모듈화를 통해서, 단 몇 줄의 메서드 호출만으로 구성된 메인 함수를 작성할 수도 있도록 도와주지만 수행절차가 간소화되어 코드가 대폭 줄었다고 할지라도

코드 각 부분의 실행 순서는 엄연히 존재하며, 근본적으로 모듈화라는 것은 그 함수가 호출될 때 참조되어 실행되어야 할 다량의 본체 코드가 존재하고 단지 이를 별도의 장소로 분리해서 정리해놓는 기술이라는 사실을 잊어서는 안 됩니다.

절차를 줄여주고 읽기에 깔끔한 프로그램으로 보이는 것은 순전히 사용자(개발자) 입장에서나 추상화를 통해 그렇게 느끼는 것이며,

시스템 내부적인 관점에서는 실제로 실행되는 코드의 양은 절차식이나 객체지향이나 큰 차이가 없으며 둘 다 한 번에 한 줄씩 '순서대로' 실행시키는 것 에는 다름이 없다는 것을 명확히 해야합니다.

집에 물건들을 정리한다고해서 물건자체의 질량이 줄어드는건 아닌것처럼 말이죠. 🤗

번외

UML 의 특징

- OOP는 유연성(Flexibility)을 가진다.

- 유연성은 캡슐화와 추상화, 다형성을 이용해서 달성된다.

- 상속은 캡슐화를 활용하고, 다형성은 상속을 이용해서 만들어진다.

- 캡슐화를 통해서 가시성(Visibility) 개념이 만들어지고, 클래스 개념이 만들어진다.

- 클래스는 타입과 필드, 그리고 메서드를 가지고 있다.

- 클래스 개념은 인터페이스(Interface), 추상 클래스(Abstract Class), 구체 클래스-(Concrete Class) 개념을 파생시킨다.

- 객체(Object)는 구체 클래스(ConcreteClass)가 가진 개념을 포함한다.

- 객체는 Identity를 가진다.(구체 클래스를 통해 클래스가 가진 개념도 가지게 되므로 Method, Field, Type도 가지게 된다.)

- 메서드는 프로토타입을 가지며, 추상 메서드는 메서드의 일종이다.

- 필드는 Reference와 Primitive로 나뉜다.

- 클래스, 메서드, 필드는 가시성을 가진다.

- 클래스는 상속 가능(Inheritable)하다.

- 메서드는 재정의 가능(Overridable)하고, 오버 로딩 가능(Overloadable)하다.

객체지향 vs 절차지향

1. 객체지향은 절차를 간소화하는 것이지, 결코 절차를 무시하는 게 아니다.

2. 절차지향은 데이터와 함수가 분리되고 통일성이 없지만, 객체지향은 좀 더 모듈화 되어 체계적이다.

3. 절차지향은 과도한 전역 변수의 사용, 스파게티 소스, 변경과 확장, 프로그램에 대한 이해

	가 어렵지만, 객체지향은 코드의 재사용성이 높다.

4. 절차지향은 프로그램의 순서와 흐름을 먼저 세우고 필요한 자료구조와 함수들을 설계하는 방

	식이고, 객체지향은 반대로 자료구조와 이를 중심으로 한 모듈들을 먼저 설계한 다음에 이들의 

	실행 순서와 흐름을 짜는 방식이다.