Today I Learned - Day 22 [객체, 그 개념에 관하여 - 1]

오늘날 프로그래밍 언어는 절차적 언어와 객체 지향 언어로 나뉘어 있다.

[유니티에서 '정보 지향'이라는 새로운 개념을 꺼내어 들기는 했으나, 사실상 유니티의 단점을 우회하기 위한 것이라서 통상적으로 쓰이는 개념은 아니다.]

하지만 이러한 '절차적'이라는 점과 '객체 지향'이라는 점을 설명해 보라고 하면 어정쩡하거나 애매한 경우가 많다.

혹자는 '반드시 위에서 부터 아래로 진행되니까 절차적 언어고, 객체 지향은 그렇지 않다'라고 서술하기도 한다.

'객체 지향은 class를 쓸 수 있으니까 그런 거고, 절차적 언어는 못 쓴다'라고 서술하는 경우도 있다.

다만, 이런 식으로 간략하게 서술 하기에는 이 두 개념은 조금 더 심오한 거 같다.

그러니 한 번 정리해 보도록 하자.

 

목차

1. 서두 ※
   1. 프로그래밍 언어의 발전사 - 객체지향은 왜 발안되었는가.
   2. Class와 Instance, Object의 정의
2. 객체지향의 4요소
   • 캡슐화
   • 추상화
   • 상속성
   • 다형성
3. 솔리드 원칙
   • 단일 책임 원칙
   • 개방 폐쇄 원칙
   • 리스코프 치환 원칙
   • 인터페이스 분리 원칙
   • 의존 역전 원칙

 

프로그래밍 언어의 발전사 - 객체지향은 왜 발안되었는가.

기존의 절차적 프로그래밍 언어에서는 위에서 부터 아래로 순차적으로 내려오기 때문에 함수와 변수를 미리 모두 선언해 둬야지 사용이 가능했다. 그런 탓에 기능 별로 코드를 모아둔다고 하기 보다는, 작동 순서에 따라서 기능을 모아뒀어야 했다. 또한, 해당 스크립트로 작동하는 함수가 있다면 그 함수를 모두 보유하고 있었어야 했다.

이런 탓에 공용으로 사용하는 함수 같은 요소들은 header로 묶어서 작성했고, 그 결과 하나의 기능을 담당하는 요소들이 모두 뿔뿔히 흩어졌어야했다.

이러한 구성으로 인해서 가독성이 심각하게 낮았고, 그 덕분에 점점 복잡해지는 코드 구성에서 유지보수를 하기가 매우 어려웠었다.

 

그런 상황에서 '하나의 기능을 담당하는 요소들을 하나로 묶어서 가독성을 높이자'는 목적으로 객체지향 언어가 출시되었던 것이다.

그 결과, 각각의 기능을 별개의 함수로 떼어서 작성, 정리하여 가독성을 크게 높일 수 있었고, 추가로 절차적 언어에서는 매우 까다로웠던 다형성을 추구할 수 있게 되면서 코드의 길이도 획기적으로 줄일 수 있었다.

 

당연하지만, 객체지향 언어라고 이점 만 있는 것은 아니다.

Stack영역이 아닌 Heap 영역을 주로 사용하다 보니 가비지 문제가 본격적으로 대두되기 시작했고, 동시에 주소를 통해서 접근해야 하는 구조 덕분에 전체적인 작동 속도는 상대적으로 느린 편이다.

당연히, 초기 객체지향 언어들은 이러한 문제점을 수동으로 개선해야 했었고, 그 덕분에 불편한 요소가 상당히 산재해 있었다. 동시에 오류나 결함도 현대에 비해서 매우 많이 발생하게 되었던 것이다.

 

이러한 상황에서 상술한 '수동으로 관리해야 한다'는 요소를 자동으로 사용되는 가비지 컬렉션으로 개선한 Java가 출시되었고, 이 또한 프로그래밍 환경에 큰 변화를 야기했었다.

다만, 이 Java는 반대로 자동으로 진행되는 영역이 너무 많은 나머지 비효율이 발생하는 경우도 있었기에, Java의 아쉬운 요소들을 개선한 언어로 C#이 출시된 것이다.

Class와 Instance, Object의 정의

위 3가지 항목은 객체 지향을 언급할 때 반드시 사용되는 용어이다.

다만, 개념에 대해서는 헷깔리는 경우가 많고, 그 정의조차도 애매한 편이다.

그러니, 전체적으로 한번 더 살펴보고 진행하자.

 

Class

프로그래머가 코딩을 통해서 직접적으로 관여하는 요소로, Instance의 기반에 해당한다고도 볼 수 있는 요소다.

엄밀히 말하면 코드 영역에 저장되는, 직접적으로 메모리에 할당되지는 않는 요소이기 때문에 객체의 동작 상의 측면에서는 별 역할을 하지는 않지만, class를 기반으로 Instance가 만들어지고, 작동하기 때문에 흔히 class '틀'으로, Instance를 그 제작물으로 묘사하곤 한다.

다만, class를 마냥 '틀'이라고 묘사하기에는 Instance의 사용 방식도 지정된다는 점에서 다소 애매하다는 느낌도 든다.

그렇기에 본인은 개인적으로 이를 '청사진'이라고 정리하는 편이다.

 

Instance

실제 메모리에 담겨져서 동작하는 요소로, class를 기반으로 제작된 '실제 작동 주체'에 해당한다.

그렇기 때문에 Unity에서도 코드 상에서는 class라고 언급하면서도 Hierachy에서는 Instance로 언급하고, 해당 객체의 생성 함수도 Instanciate인 것.

코딩에서 중요한 요소가 class라면, 실 구동에서 중요한 요소는 Instance인 셈이다.

 

Object

객체라는 개념 그 자체를 지칭하는 용어.

Class와 Instance 모두를 아우르는 것으로 볼 수도 있지만, 개인적으로는 Class와 Instance는 이 Object를 구현하기 위한 기술 내지는 기능에 해당하고, Object는 이 둘을 통해서 구현하고자 하는 최종 목표라고 보고 있다.

물론, 구분해서 서술하는 경우라면 그렇다는 것으로, 위 둘 모두 객체를 구성하기 위한 요소이므로, 이들을 Object로 뭉뚱그려서 서술해도 될 것이라고 생각한다.

 

즉, 객체지향 프로그래밍은 Class와 Instance를 통해서 구현한 Object 구성을 이용해서 프로그램을 구동하도록 개발하는 것이라고 볼 수 있다.

 

 

※ 2부에서 계속...

 

2부: https://lsu0503.tistory.com/77

Today I Learned - Day 23 [객체, 그 개념에 관하여 - 2]

3부: https://lsu0503.tistory.com/78

Today I Learned - Day 24 [객체, 그 개념에 대하여 - 3]