객체지향과 절차지향 (Object Oriented Programing VS Procedural Programing)

객체지향(OOP)? 절차지향(PP)? 

평소처럼 프로그래밍 공부를 하던 와중 객체지향, 절차 지향의 차이를 몰라서 개념을 확실히 잡아야겠다는 생각이 들어 검색해보았는데 스파게티코드님이 가장 깔끔하고 명확하게 설명해주셔서 그분의 글을 참고하여 포스팅을 하려고 한다.

 

위 사진은 절차지향과 객체지향의 차이점을 설명하는 단순화된 사례이다. 

먼저 절차지향 방식을 보면, 차근차근 순서대로 따라가는 전형적인 절차식 프로그램임에 틀림이 없다. 그렇다면 객체지향 방식을 살펴보자. 

개별적으로 참조되고 호출되는 변수들과 함수들을 '객체'라는 틀로 묶어서 사용했다는 것은 둘째 치고, 순서대로 차근차근 진행되는 실행방식에 있어서는 차이점이 없는 것 같다.

객체지향을 설명할 때는 항상 비교대상으로 "절차지향" 방식이 따라붙는다. 그러다 보니 마치 객체지향 프로그래밍은 실행절차에 영향을 받지 않는 것처럼 보인다. 그러나 위의 알고리즘을 보듯이, 객체지향 방식으로 개발한 프로그램도 분명히 일련의 절차에 따라 실행된다. 결국 "절차지향"이라는 용어 선택이 이 모든 혼돈을 초래한 주범이라는 것이다.

사실 객체지향의 개념과 특징을 설명하는 데 있어서​ 굳이 절차지향 방식을 가져와서 서로 비교할 필요는 없다. 객체란 기존의 방식인 변수 따로, 함수 따로의 분산적이고 통일성 없는 추상화 과정을 통합하여 표현 대상(문제 해결 대상)을 좀 더 모듈화 하기 쉽게 도와주는 도구에 불과하며 객체지향 프로그래밍은 객체의 디자인을 한 뒤에 이들의 데이터 플로우를 짜고 진행 시나리오를 설계해나가는 방식의 개발 방법론일 뿐이다.

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

한 번에 프로그램 한 문장씩만을 읽어 들여와서 실행시키는 폰 노이만 컴퓨터 구조를 사용하는 한, 객체지향 프로그래밍이라고 절차성을 무시하는 프로그램을 짤 수는 없다. 이렇듯, "객체지향"과 "절차식"의 개념은 애초에 비교대상이 아니며 카테고리 자체가 다른 것이다.

"절차지향"이라는 이름을 써야 한다면 "절차지향 프로그래밍은 프로그램의 순서와 흐름을 먼저 세우고 필요한 자료구조와 함수들을 설계하는 방식이고, 객체지향 프로그래밍은 반대로 자료구조와 이를 중심으로 한 모듈들을 먼저 설계한 다음에 이들의 실행 순서와 흐름을 짜는 방식이다" 정도의 설명을 추가하는 것만으로도 그렇게까지 헷갈릴 일은 없을 것이다. 그게 아니면, 절차지향이라는 이름 대신 차라리 "비 객체지향 방식"이라고 쓰는 게 나을지도 모른다.

앞서 살펴본 자판기 프로그램 예시에서도 볼 수 있듯이, 여러 책에서는 절차지향과 객체지향을 비교할 때 대부분이 절차지향은 "순서도"로, 객체지향은 "클래스 다이어그램"으로 도표를 그려서 비교해놔서 혼란을 가중시킨다. 애당초 순서도와 클래스 다이어그램은 서로 용도부터 다른 도구이다. 알다시피 순서도는 알고리즘을 표현하기 위한 도구이고, 클래스 다이어그램은 자료구조 간의 상호관계를 기술하기 위한 도구이다.

객체지향 방식으로 설계하더라도 그 알고리즘을 표현할 때 당연히 순서도를 활용할 수 있으며, 절차식 방식으로 설계하더라도 클래스 다이어그램을 이용하여 데이터들과 모듈 간의 관계를 설명할 수 있다. 물론 확실히 절차식 프로그래밍에서는 거의 순서도 위주로, 반대로 객체지향 프로그래밍에서는 UML 위주로 설계가 이루어지는 것은 엄연한 사실이다. 그러나 클래스 다이어그램의 개념과 용도에 익숙하지 않은 상태에서 저 그림만 본다면 객체지향 프로그램은 모듈들이 실시간으로 정보를 주고받고, 순서에 상관없이 동시다발적으로 실행된다는 착각을 심어줄 수도 있다.

객체지향은 기존의 방식에 비해 프로그램의 수행절차를 간소화해주지만, 절차를 무시하는 것은 결코 아니다. 깔끔한 모듈화를 통해서, 단 몇 줄의 메서드 호출만으로 구성된 메인 함수를 작성할 수도 있도록 도와주지만 수행절차가 간소화되어 코드가 대폭 줄었다고 할지라도 코드 각 부분의 실행 순서는 엄연히 존재하며, 근본적으로 모듈화라는 것은 그 함수가 호출될 때 참조되어 실행되어야 할 다량의 본체 코드가 존재하고 단지 이를 별도의 장소로 분리해서 정리해놓는 기술이라는 사실을 잊어서는 안 된다. 절차를 줄여주고 읽기에 깔끔한 프로그램으로 보이는 것은 순전히 사용자(개발자) 입장에서나 추상화를 통해 그렇게 느끼는 것이며, 시스템 내부적인 관점에서는 실제로 실행되는 코드의 양은 절차식이나 객체지향이나 큰 차이가 없으며 둘 다 한 번에 한 줄씩 '순서대로' 실행시키는 것에는 다름이 없다는 것을 명확히 이해해야 한다.

객체지향 vs 절차지향

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

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

3. 절차지향은 과도한 전역 변수의 사용, 스파게티 소스, 변경과 확장, 프로그램에 대한 이해가 어렵지만, 객체지향은 코드의 재사용성이 높다.

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

객체지향의 프로그래밍의 개념들

캡슐화	데이터와 함수들을 객체 안에 넣어서 묶는다. 캡슐화된 객체들은 다른 프로그래머가 사용하기 편리하다. 또한 수많은 테스트와 디버그를 마쳤기 때문에 안심하고 사용할 수가 있다.
정보 은닉	객체 간의 모든 통신은 함수 호출을 통해야 하며 객체의 함수를 가지고 상호작용 함으로써 객체 내부 구현의 세부 사항은 외부 세계로부터 감춰진다. 내부 데이터가 숨겨져 있다는 것은 프로그램의 다른 부분에 영향을 미치지 않고 쉽게 변경될 수 있음을 의미한다.
상속과 다형성	자식 클래스는 부모 클래스를 물려받으며 확장 가능하며 기존의 코드를 재사용하는 것이 가능하다. 서로 다른 타입에 속하는 객체들이 같은 이름의 멤버 함수에 응답하여서 서로 다른 동작을 보여주는 것이 가능하다.
쉬운 디버깅	절차지향 프로그램에서 하나의 변수를 100개의 함수가 사용하고 있고, 객체 지향 프로그램에서는 100개의 클래스와 각 클래스당 10개의 멤버 함수를 가지고 있다고 가정해보자. 프로그램에 문제가 생겼을 시 클래스 안에 10개의 멤버 함수를 검사하는 편이 1000개의 함수를 검사하는 것보다 훨씬 낫다.

 

다양한 요구사항을 수용할 수 있는 '유연성'은 객체지향의 근본이자 핵심이다. 객체지향 프로그래밍은 유연성을 가지기에 가치가 높은 것이다. 그리고 유연성은 캡슐화, 추상화, 다형성을 이용해서 달성할 수 있다.

 

객체지향 개념들 간의 관계 UML

간략히 설명하자면 다음과 같다.

• OOP는 유연성(Flexibility)을 가진다.
• 유연성은 캡슐화와 추상화, 다형성을 이용해서 달성된다.
• 상속은 캡슐화를 활용하고, 다형성은 상속을 이용해서 만들어진다.
• 캡슐화를 통해서 가시성(Visibility) 개념이 만들어지고, 클래스 개념이 만들어진다.
• 클래스는 타입과 필드, 그리고 메서드를 가지고 있다.
• 클래스 개념은 인터페이스(Interface), 추상 클래스(Abstract Class), 구체 클래스(Concrete Class) 개념을 파생시킨다.
• 객체(Object)는 구체 클래스(ConcreteClass)가 가진 개념을 포함한다.
• 객체는 Identity를 가진다.(구체 클래스를 통해 클래스가 가진 개념도 가지게 되므로 Method, Field, Type도 가지게 된다.)
• 메서드는 프로토타입을 가지며, 추상 메서드는 메서드의 일종이다.
• 필드는 Reference와 Primitive로 나뉜다.
• 클래스, 메서드, 필드는 가시성을 가진다.
• 클래스는 상속 가능(Inheritable)하다.
• 메서드는 재정의 가능(Overridable)하고, 오버 로딩 가능(Overloadable)하다.

 

- 절차지향 방식과 객체지향 방식 요약

Procedural Programming
1. 전통적인 프로그래밍 방식
2. 데이터와 이를 처리하기 위한 기능들이 별도로 분리
3. 프로젝트의 규모가 커질수록
관련된 데이터가 여러곳에 분산
구성요소들 간의 결합도(Coupling)가 높아진다
데이터 무결성(Integrity) 보장이 어려워진다.
개발 생산성이 크게 저하된다.

Object-Oriented programming
1. 관련된 데이터와 오퍼레이션을 그룹화하는 "객체" 위주의 프로그래밍 방식
2. 불필요한 결합도를 줄임
3. 전체 데이터와 오퍼레이션들이 객체단위로 분할되기 때문에 부담이 적음
4. 데이터 무결성 보장이 용이함
5. 개발 생산성이 떨어지지 않는다.

 

감사합니다.