객체 지향 프로그래밍

 

1. 개요
2. 역사
2.1. 시작과 발전
2.2. 지원하는 언어
3. 요소
3.1. 캡슐화(Encapsulation)
3.1.1. 정보 은닉(Information Hiding)
3.3. 다형성(Polymorphism)
5. 장단점
6. 기타
6.1. 교육의 어려움
6.2. C언어와 객체지향
7. 관련 문서


1. 개요

漢: 客體 指向 — / En: Object-Oriented Programming (OOP)
프로그램 설계방법론이자 개념의 일종.
프로그램을 단순히 데이터와 처리 방법으로 나누는 것이 아니라, 프로그램을 수많은 '객체(object)'라는 기본 단위로 나누고 이들의 상호작용으로 서술하는 방식이다. 객체란 하나의 역할을 수행하는 '메소드와 변수(데이터)'의 묶음으로 봐야 한다.
서술의 편의상 객체지향을 Java 위주로 소개하고 있고 class나 public 같은 용어를 사용했다. 이 경우만 객체지향에 해당하는 것으로 오해하지 않게 주의해야 한다. 모든 언어가 class나 접근 제한자(public이나 private)를 사용하지는 않는다. 대표적인 예로 JavaScript는 프로토타입 객체지향을 사용하고 있고 Python에는 접근제한자가 없다. 객체지향은 특정 언어가 아니라 개념이다. "클래스는 객체이며 구조체는 객체가 아닌 데이터의 집합"이라는 설명 역시 틀렸고, 특정 언어가 객체지향 언어라는 말도 완전히 틀린 표현이다.

2. 역사


2.1. 시작과 발전

초기 프로그래밍 방식은 절차적 프로그래밍 방식이었다. 학교대사전의 고등학생 알고리즘처럼 입력을 받아 명시된 순서대로 처리한 다음, 그 결과를 내는 것뿐이라는 생각이 지배적이었다. 프로그램을 명령어의 모음으로 인식한 것이다. 또한 프로그래밍이란 어떻게 어떤 논리를 어떤 순서대로 써나가는 것인가로 간주되었다. 즉, 프로그램 자체가 가지는 기능에 대해서만 신경을 썼지, 이 프로그램이 대체 어떤 데이터를 취급하는 것인가에는 그다지 관심이 없었던 것이다.
그러나, 이 방식은 간단한 알고리즘이면 모를까 조금만 복잡해지면 순서도로 나타내는 것이 불가능할 정도로 꼬인 "스파게티 코드"를 만들게 된다. 간단히 말해서 스타크래프트를 위의 순서도로 그려야 된다고 생각해봐라! 이렇게 꼬여버린 코드는 다른 사람이 보고 이해하는 것이 거의 불가능할 뿐더러 심지어는 작성한 본인조차도 유지보수에 어려움을 겪게 된다. 명령어의 양이 많아지는 것은 기본이고, 특정 코드 부분은 어디에 사용되는 코드고 해당 코드 부분은 어디까지 이어지는지의 흐름을 파악하기도 힘들어지며, 중복 코드 대처도 매우 골치아프다. OOP를 사용하면 코드의 중복을 어느 정도 줄일 수 있고 입력 코드, 계산 코드와 결과 출력 코드 등 코드의 역할 분담을 좀 더 확실하게 할 수 있어서 가독성이 높아질 수 있다.
이 문제를 해결하기 위해 에츠허르 다익스트라가 1968년 GOTO문의 해로움이라는 논문에서 프로그램을 함수(procedure) 단위로 나누고 프로시져끼리 호출을 하는 구조적 프로그래밍 방식을 제안하면서 이러한 위기를 벗어나게 된다. 프로그램이라는 큰 문제를 해결하기 위해 그것을 몇개의 작은 문제들로 나누어 해결하기 때문에 하향식(Top-down) 방식이라고도 한다.
[image]
하지만 함수는 데이터의 처리 방법을 구조화했을뿐, 데이터 자체는 구조화하지 못했다. 이는 전역 네임스페이스 포화 문제(변수 이름을 다 써서 '''이름 짓기도 힘든 상황'''(...))를 낳게 되었다.[1] 게다가 실행 콘텍스트를 저장할 마땅한 방법이 없어지는 문제가 생겼다. 실행 콘텍스트는 특히 GUI에서 중요해지는데 어떤 창의 현재 상태에 따라 함수가 실행해야 하는 동작 방식이 달라지기 때문이다. 또한 엉뚱한 데이터가 엉뚱한 함수에 전달돼서 데이터를 오염시키는 문제가 발생하고 그런 가능성 때문에 프로그래머가 한 함수의 작동에 영향을 받는 변수를 조사해야 할 때 모든 변수를 다 조사해야 하는 어려움에 봉착했다. 변수의 갯수가 수백 개 이하인 코드에서야 이게 사람의 힘으로 가능했지 코드의 덩치가 커지면서 함수가 접근할 수 있는 데이터의 범위에 명시적인 제한을 걸어야 하는 상황이 도래했다. 이를 지역 변수나 구조체(struct) 등으로 어찌 제어하고 있기는 했지만 더 근본적인 해결책이 필요했다.
이를 극복하기 위한 대안으로 등장한 것이 바로 객체 지향 프로그래밍이다. 큰 문제를 작게 쪼개는 것이 아니라, 먼저 작은 문제들을 해결할 수 있는 객체들을 만든 뒤, 이 객체들을 조합해서 큰 문제를 해결하는 상향식(Bottom-up) 해결법을 도입한 것이다. 이 객체란 것을 일단 한번 독립성/신뢰성이 높게 만들어 놓기만 하면 그 이후엔 그 객체를 수정 없이 재사용할 수 있으므로 개발 기간과 비용이 대폭 줄어들게 된다.
객체 지향 프로그래밍은 등장 당시에는 기존의 절차적 프로그래밍과 비교해 매우 이질적이고, 당시 컴퓨터의 처리능력이 별로 좋지 않아서 별 주목을 받지 못하였다. 그러다가 GUI가 등장하면서 객체 지향 프로그래밍이 급부상하게 된다. 화면에 떠 있는 여러 개의 창은 각자의 실행 콘텍스트를 가지는데 콘텍스트의 현재 상태(활성화, 비활성화, 최소화 등)에 따라 같은 명령에도 다른 결과를 내보내야 했으며 사용자 상호작용을 위해 이벤트 처리도 수행해야 했다. 특히 이벤트 처리는 비동기적인 속성 때문에 기존 절차적 프로그래밍에서는 일종의 횡단 관심사가 되어 버려 코드 전체에 이벤트 처리 코드가 흩어져 있게 되는 문제가 있었다. 그래서 OOP를 도입하여 이벤트를 받았을 때 수행되는 기능(Event Handler, Callback)을 구현할 수 있는 단일 인터페이스를 정의하고, 프로그래머들은 이를 필요한 형태로 알아서 구현하며, 특정 이벤트가 일어났을 때 실행되어야 하는 기능들을 등록한 다음, 운영체제나 응용프로그램이 실제로 해당 이벤트가 발생했을 때 해당 이벤트에 등록된 이벤트 핸들러/콜백을 주욱 실행하기만 하면 되는 구조가 본격적으로 확산되면서 OOP 또한 빠르게 확산되었다.
단, 이벤트 드리븐 방식은 객체 지향 프로그래밍과 별개의 개념이다. 사실 이벤트 드리븐 방식은 객체 지향보다 함수형 프로그래밍 언어에서 훨씬 더 잘 지원한다. 그 예시로, 같은 일을 하는 Java와 Scala 코드의 GUI 로직을 보면 Scala 쪽이 압도적으로 단순하다는 것을 알 수 있다. 다만 기존 절차형 프로그래밍 언어가 함수를 일급 객체로 지원하지 않아 콜백 구현이 어려운 문제가 있었고(절차형인 C언어에서는 함수 포인터를 사용한다) 마침 등장한 객체 지향 언어가 인터페이스라는 개념을 제공했기에 이벤트 드리븐 방식에 좀 더 어울렸을 뿐이다. 객체 지향 프로그래밍 개념이 나올 당시에도 LISP 등 함수형 언어가 있긴 했으나 기존 프로그래머가 사용하기에는 너무 고수준의 개념을 다루고 있었고 성능도 너무 낮았기 때문에 당시에는 주목받지 못했다. 당장 for 루프로 리스트 처리가 가능한데 리스트 해석이니 map/reduce니 떠들어봤자 현업 프로그래머의 귀에 들어갈 리가 없었다. 물론 지금은 고차 함수나 클로저 같은 개념까지 도입해야 할 정도로 프로그램의 복잡도가 증가했기 때문에 관심을 보이고 있다. 현대에 만들어지는 프로그램은 그 정도로 복잡해졌다.
객체 지향 프로그램이 복잡해지면서 이를 간결하게 정리할 필요성이 생긴 관계로 '디자인 패턴'이라는 것이 생겼다. 프로그래밍 형식을 정하는 일종의 약속으로, 이는 특히 협업을 전제로 한 환경에서 특히 강조되고 있다.

2.2. 지원하는 언어

  • Smalltalk 언어
앨런 케이가 1972년 팔로 알토 리서치 센터(PARC)에서 만든 Smalltalk가 최초로 OOP를 지원한 프로그램이다. 시뮬레이션 프로그래밍 언어인 시뮬라-67에서 영향을 받았다.
스몰토크는 앨런 케이가 "누구나 쉽게 사용할 수 있는 컴퓨터"를 만들려고 했던 목적에 따라 만들어졌다. 문제는 앨런 케이가 글을 읽고 쓸 수만 있으면 4-5세의 아이들도 프로그래밍 할 수 있는 것을 이상적인 목표로 했기 때문에 프로그래밍을 하고자 하는 목표를 수학적 논리구조(알고리즘)로 개념화한 뒤에 그에 따라 프로그래밍 하는 게 아니고[2] 비 수학적인 사고로 문제를 해결하도록 언어가 설계되어 있었고, 이 때문에 모든 것을 객체 단위로 분해하고 그 객체들이 메세지를 전달하여 문제를 해결하도록 프로그래밍을 해야만 한다.
  • Ruby와 Python
Ruby: Smalltalk의 계보를 잇는 순수 객체지향 언어. 기존의 C++나 Java 등에 비해서 난이도가 쉽다.
Python: 역시 순수 객체지향을 지원하고 있다. Ruby와 비슷한 구조를 가지고 있으며, 미세한 명령어나 기법 차이 등이 있을 뿐, 거의 형제처럼 가까운 언어들이다. 생활코딩에서는 이 두 언어를 거의 똑같은 언어라고 설명하면서 루비와 파이썬의 코딩을 동시에 가르치는 강좌를 개설해 놓았다.
  • C언어에 객체 처리 기능 추가
브레스 콕스와 톰 러브는 스몰토크를 보고 새로운 시각으로 객체지향을 바라보았는데 그것은 소스 코드의 수정없는 재활용이었다. 그들은 이 개념을 실제 언어에 적용하여 1983년도에 스몰토크의 객체 처리 방식을 C언어에 추가했다. C언어의 표준을 지키면서 스몰토크 방식의 객체 처리 기능을 추가한 것이다. 이렇게 표준 언어에 기능을 추가하는 것을 슈퍼셋(Superset)이리고 한다. 반대로 표준언어의 기능을 축소한 것을 서브셋(Subset)이라고 한다. 컴파일러 개발 방법을 교육할 목적으로 만든 Small-C가 대표적인 서브셋이다.
  • C++
1983년에 비아르네 스트로우스트루프가 C언어를 확장시킨 C++를 발표했다.
  • Objective-C
1983년에 브래드 콕스와 톰 러브가 C언어에서 파생된 Objective-C를 만들어 발표했고 실제 유용하다는 것을 실증하였다. 그리고, Objective-C는 1989년 당시 가장 혁신적인 운영체제였던 NeXTSTEP을 개발할 때 사용되었다. NeXTSTEP은 1996년도에 Apple에 인수되어 2001년도에 출시된 Mac OS X의 기반이 되었다.
  • 기타 여러 언어들
이 두 언어의 성공으로 이후 Java, C\#, Objective-Pascal 등 많은 객체 지향 언어들이 순수한 객체 지향보다는 기존의 프로그래밍 언어에 객체 지향 요소를 확장하거나 추가한 형태로 만들어지게 되었다.

3. 요소


3.1. 캡슐화(Encapsulation)

변수와 함수를 하나의 단위로 묶는 것을 의미한다. 즉, 데이터의 번들링(Bundling)이다. 대개 프로그래밍 언어에서 이 번들링은 클래스를 통해 구현되고, 해당 클래스의 인스턴스 생성을 통해 클래스 안에 포함된 멤버 변수와 메소드에 쉽게 접근할 수 있다. 클래스는 객체 지향 프로그래밍을 지원하는 거의 대부분의 언어가 제공하는 제1요소이다.

3.1.1. 정보 은닉(Information Hiding)

프로그램의 세부 구현을 외부로 드러나지 않도록 특정 모듈 내부로 감추는 것이다. 내부의 구현은 감추고 모듈 내에서의 응집도를 높이며, 외부로의 노출을 최소화하여 모듈 간의 결합도를 떨어뜨려 유연함과 유지보수성을 높이는 개념은 거의 모든 현대 프로그래밍 언어에 녹아 있다. 많은 객체 지향 언어에서 사용되는 클래스를 기준으로 보면, 클래스 외부에서는 바깥으로 노출된 특정 메소드에만 접근이 가능하며 클래스 내부에서 어떤 식으로 처리가 이루어지는지는 알지 못하도록 설계된다.
일반적으로 세 종류의 접근 제한이 사용된다.
  • public: 클래스의 외부에서 사용 가능하도록 노출시키는 것이다.
  • protected: 다른 클래스에게는 노출되지 않지만, 상속받은 자식 클래스에게는 노출되는 것이다.
  • private: 클래스의 내부에서만 사용되며 외부로 노출되지 않는다.
보통 캡슐화와 정보 은닉을 묶어서 생각하는 경우가 많은데, 정보 은닉은 캡슐화로부터 파생된 보조 개념이지 '캡슐화 = 정보 은닉'은 아니다. Python은 정보 은닉을 지원하지 않지만 클래스를 통한 캡슐화를 지원하기 때문에 객체지향 언어로 분류된다.

3.2. 상속(Inheritance)

상속은 자식 클래스가 부모 클래스의 특성과 기능을 그대로 물려받는 것을 말한다. 기능의 일부분을 변경해야 할 경우 자식 클래스에서 상속받은 그 기능만을 수정해서 다시 정의하게 되는데, 이러한 작업을 '오버라이딩(Overriding)'이라고 한다. 상속은 캡슐화를 유지하면서도 클래스의 재사용이 용이하도록 해 준다.
자세한 내용은 문서 참조.

3.3. 다형성(Polymorphism)

하나의 변수, 또는 함수가 상황에 따라 다른 의미로 해석될 수 있는 것을 말한다.
  • 서브타입 다형성(Subtype Polymorphism / Inclusion Polymorphism / Subtyping)
우리가 일반적으로 접하는 OOP의 그것. 기초 클래스 또는 어떠한 인터페이스를 구현하는 상위 클래스를 생성하고, 해당 클래스를 상속받는 다수의 하위 클래스들을 만들어 상위 클래스의 포인터나 참조변수 등이 하위 클래스의 객체를 참조하게 하는 것이다. 이 때 각각의 하위 클래스는 상위 클래스의 메소드 위에 자신의 메소드를 덮어쓰는 메소드 오버라이딩(Method overriding)을 수행하며, 상위 클래스의 참조변수가 어떤 하위 클래스의 객체를 참조하느냐에 따라 호출되는 메소드가 달라진다.[3] Java, C++, C\#, Python, Ruby 등의 객체 지향 언어들은 기본적으로 지원하는 개념.
  • 매개변수 다형성(Parametric Polymorphism)
타입을 매개변수로 받아 새로운 타입을 되돌려주는 기능이다. 타입 매개변수를 정의한 클래스 혹은 메소드는 사용할 때 매개변수에 타입을 지정하게 되며, 컴파일 시 지정한 타입에 따라 해석된다.
  • 템플릿(Template)
C++에서 사용하는 개념으로, 타입 매개변수를 입력한 타입으로 치환한 코드를 생성하는 방식이다. 타입 뿐 아니라 변수도 입력할 수 있으며, 객체 내부에서 연산이나 함수 호출을 할 수 있지만, 해당 연산이나 함수가 정의되지 않은 타입을 매개변수로 넣으면 컴파일 에러가 발생하며 컴파일이 느려지고 파일이 커진다.
  • 제네릭(Generic)
Java와 C# 등에 도입된 개념으로, 지정한 타입 매개변수에 해당하는 타입만을 사용하겠다고 약속하는 방식이다. 타입 매개변수가 특정 객체를 상속할 경우 상속하는 객체의 함수는 호출할 수 있지만 그렇지 않을 경우 타입 매개변수로 지정된 객체의 멤버에는 접근할 수 없다.
  • 임시 다형성(Ad hoc Polymorphism)
    • 함수 오버로딩(Function overloading)
C++과 C#, Java에서는 함수 오버로딩을 통해 동일한 이름의 함수를 매개변수에 따라 다른 기능으로 동작하도록 할 수 있다. 함수 오버로딩을 너무 많이 사용하면 전체적인 코드의 유지보수가 어려워지므로, 템플릿 또는 제네릭으로 대체하는 것이 일반적이다.
  • 연산자 오버로딩(Operator overloading)
C++, C# 등에서는 연산자를 오버로딩해서 기본 연산자가 해당 클래스에 맞는 역할을 수행하게 하는 것이 가능하다. Java에서는 연산자의 오버로딩이 불가능하다. Perl 6나 Smalltalk, F#, Kotlin 등 연산자의 신규 정의가 가능한 언어도 있다. 한글 위키백과의 연산자 오버로딩에 대한 프로그래밍 언어 분류
  • 강제 다형성(Coercion Polymorphism)
    • 묵시적 형 변환(Implicit type coercion)
'double a = 30;'이라는 식이 실행되면 int형 값 30은 double로 묵시적 형 변환이 이루어진다. double은 int보다 크기가 큰 자료형이므로, 이러한 형 변환을 자료형 승급(Type promotion)이라고 한다. C++의 변환 생성자에 의한 형 변환도 묵시적 변환에 속하며, 이를 막으려면 생성자 앞에 explicit 키워드를 추가해야 한다.
  • 명시적 형 변환(Explicit type coercion)
'double a = (double)30;'이라는 식은 위와 동일한 결과를 내지만, (double)을 통해 int형 값 30이 double형으로 변환됨을 명시적으로 표현하였다.

4. 원칙


5. 장단점

  • 데이터 클래스의 상속이라는 개념은 굉장히 뛰어나지만 마찬가지로 굉장히 복잡한 특성을 지니게 해준다. 이 OOP 특성 덕분에 면밀한 자료 분석[4], 개발시간 단축[5], 좀더 정확한 코딩[6]을 보증하지만 코드의 난이도가 급상승한다. 한 마디로 어려워진다. 특히, 다중 상속이 되면 엄청 복잡해진다. 그래서 대다수의 OOP 언어들은 다중 상속을 지원하지 않았고 실제 구현이 전혀 없는 껍데기인 인터페이스만 추가로 상속할 수 있게 했는데, 이게 또 코드의 재사용성을 현저하게 떨어뜨리는 문제가 있어서[7] 최근엔 믹스인이나 트레이트같이 다중상속을 할 수 있는 방법을 찾고 있다. 상속이 복잡하게 얽혀 소스 분석이 어려워진 상태는 라자냐 코드라고 곧잘 불리는 편.
  • 클래스는 오로지 관련 데이터만을 정의하기 때문에, 한 클래스의 인스턴스가 수행될 때 다른 프로그램의 데이터를 절대로 건드릴 수 없게 된다. 덕분에 높은 시스템 보안을 제공하고, 자료 훼손을 방지하는 효과가 있다. 하지만 public 변수를 남발해 버리면... 더 이상의 자세한 설명은 생략한다. 당연하지만, 이는 프로그램 내에서의 각 인스턴스간 내부적인 접근의 범위를 제한하는 것이다. 외부 프로그램의 메모리 접근 문제와는 다른 범주. 외부에서의 메모리 접근까지 차단한다면 메모리 변조는 어떻게 된단 말인가. 애초에 운영체제에서 메모리 관리도 못하게 될 것이다. Visual Studio 6.0의 C++는 데이터베이스의 자료 처리 시 변수를 모두 public으로 처리했었다. 이 이유는 데이터베이스의 필드가 50개이면 get과 set 메소드를 모두 구현해주면 100개의 메소드가 만들어져야 했기 때문이다. 변수 50개와 메소드 100개를 다 150개를 키보드로 쳐야 한다.[8] 생각만 해도 일할 기분이 안난다. 이건 Java도 마찬가지다. 변수의 get과 set 메소드 구현은 어찌됐든 굉장히 귀찮은 작업이다. 데이터의 은닉도 중요하지만 프로그래머의 손가락 건강도 생각해 봐야 한다. C#은 2.0부터 프로퍼티 하나만 선언해 주면 되기 때문에 큰 문제는 없다.
구체적인 해당 사례를 알 수 없으니 원문을 남겨두지만, C++ 컴파일러라면 어느 것이든 상속과 타입 선언, 오버로딩 등을 사용하면 public 변수를 사용하는 것과 비슷한 코스트로 메소드를 사용한 입출력을 구현할 수 있다. 메소드가 없으면 클라이언트의 변화무쌍한 갈아엎기에 대한 대응력이 떨어져서 오히려 더 피곤해질 위험이 높은 코드다.
  • 클래스의 정의는 최초로 생성한 프로그램뿐 아니라 다른 OOP에서도 똑같이 사용될 수 있다. 그리고, 이런 이유로 네트워크에 쉽게 분산 사용이 가능하지만 프로그래머에게는 아주 힘든 노력을 강요한다. 네트워크 통신이라는 것은 호환성을 위해 7bit ASCII 코드로 전송한다. 1960년대 만들어진 통신기기를 사용하는 곳도 아직 있기 때문이다. 이 때문에 Quarter-Print, Base64나 UTF-8 같은 것이 만들어진 것이다. 결국 객체도 7bit ASCII 코드로 전송을 해야 한다. 메모리상의 객체 정보를 ASCII 코드화 하는 것을 직렬화(Serialization)라고 하고 ASCII 코드를 다시 객체화 하는 것을 역직렬화(Deserialization)라고 한다. 하지만 마법처럼 그냥 되는 게 아니고 "직렬화 인터페이스"를 프로그래머가 직접 구현했을 때만 가능하다. Java를 비롯한 대다수의 객체 지향 언어들은 직렬화-역직렬화 인터페이스를 기본적으로 제공하고 있다. 이러한 아이디어를 발전시킨 것이 CORBA와 MS의 COM/DCOM/COM+이다. 최근에는 SOAP나 JSON, XML-RPC 등 텍스트 기반의 직렬화 기술도 많이 사용된다. Java에는 Java Runtime끼리 통신하기 위한 RMI(Remote Method Invocation)도 지원한다.
  • 데이터 클래스 개념은 언어에 정의되지 않은 새로운 데이터 형식을 프로그래머가 임의로 정할 수 있도록 해준다.
  • 캡슐화와 격리 구조 설계로 인한 성능 하락이 있다. 거의 대부분의 객체지향 언어에서 기능을 묶으면 결국 함수 호출이 추가로 들어가거나 계산식 중간에 포인터 연산 등이 필요해지며, 멤버 함수 같은 경우 어느 객체의 함수인지 지정해야 하기 때문에 추가 포인터 크기와 연산 비용이 들어간다. 인라인 함수와 컴파일러 최적화(특히 RVO(Return Value Optimization)) 등의 방법으로 어느정도는 격차를 줄여주나 역시 그냥 절차적 프로그래밍보다는 무거워진다.
  • 개념을 기준으로 나누다보니 반복 연산이 컴퓨터 친화적이지 않고, 특히 배열 자료구조를 적용하기 힘들어진다. 객체 하나하나를 따로 캡슐화시키고 상속시 부모만 같으면 자식의 종류를 신경쓰지 않다보니 각자의 메모리 크기가 달라지며, 결국 고정된 연속 메모리에 담을 수가 없게 된다. 메모리 할당을 배열로 하지 못하게 되니 따로따로 생성하게 되는데 이렇게 각각의 객체의 생성과 파괴가 반복되면 메모리 단편화라는 문제가 생기게 된다. 가비지 컬렉션 기능이 만들어진 이유 중 하나. 또 연속 메모리를 쓰기 힘들어진다는 건 캐시의 효율적 사용에 큰 문제가 생긴다는 뜻이기도 해서 성능 격차는 더 벌어지게 된다. 이를 해결하는 코딩 패러다임으로 DOP(Data Oriented Programming)가 있고 구현 방법으로 메모리 풀이 있다.
  • 객체 하나하나를 따로 나누는데 주력하다보니 서로 비슷한 처리를 하는 코드가 서로를 건드릴 수 없게 되었고 이를 해결하기 위해 getter(접근자: 값을 반환하는 메소드), setter(설정자: 필드에 값을 저장하는 메소드)사용이 너무 많아졌다. 이 과정에서 캡슐화가 깨지고 그냥 public으로 공개한 경우나 마찬가지인 상태가 되어 의미가 퇴색되었고, 다른 프로그래밍 패러다임이 필요해졌다. AOP(Aspect Oriented Programming)는 모든 코드 하나하나를 별개의 객체로 분리하기보다 '어떤 일을 어디서 처리하는가' 에 더 중점을 두어 큰 범위로 묶어주어 모듈화 효율을 개선시켰고, 현대 프로그래밍 언어와 코드들은 원본 객체 지향 방식을 그냥 그대로 적용하는 경우가 드물다.

6. 기타

최근 주목을 받고있는 함수형 패러다임과는 다소 상반된 위치에 있다. OOP의 경우 프로그램 유지보수시 데이터 추가는 새로운 클래스를 더하는 것으로 비교적 간단하게 가능하지만 operation set을 변경할 때는 관련된 다수 클래스를 수정해야 하므로 난잡해지는 경향이 있다. 반대로 함수형 패러다임에서는 operation set의 추가는 간단하지만 데이터 추가는 관련된 다수의 함수를 바꿔야 하므로 난해한 점이 있다.
주의할 점은 OOP와 함수형 패러다임이 상반된 위치에 있긴 하지만 대비되는 개념은 아니며, 요즘에는 함수형 언어에도 OOP 개념을 추가한다든가(F#), 반대로 객체지향 언어에 함수형 패러다임을 추가하는(C#, C++, Python...) 등 멀티패러다임 추세로 가고 있다.
클래스가 있어야만 객체 지향 프로그래밍 언어라고 생각할 수도 있지만, 사실 클래스 없는 OOP 언어도 꽤 있다. 프로토타입을 사용하는 JavaScript[9], 액션스크립트 2.0[10], 트레이트(Trait)를 사용하는 Rust 등.

6.1. 교육의 어려움

프로그래밍을 배울 때 만나게 되는 난관이기도 하다. C를 배운 뒤 C++을 배우는 상황에서 특히 심하긴 한데, 곧바로 Java나 Python으로 배우기 시작하는 경우에도 마찬가지다. 왜냐하면 이전까지 배웠던 것은 프로그래밍 언어의 문법이었다면(절차적 프로그래밍으로서의 문법), OOP는 가장 문제가 덜 생기는 방향으로 코딩하게끔 하는 가이드라인이기 때문이다.(권장사항) 이제 막 알파벳과 기초 영문법을 뗀 학생에게 수사법 내지는 논리적 작문을 가르치는 것과 동일한 것이다.
이 문제라는 것도 수천, 수만 줄짜리 코드를 수년간 유지보수할 때나 몸에 와닿을 텐데, 기껏해야 과제 제출하고 다시 손대지 않을 길어야 수백 줄짜리 코드나 짜봤을 학생들에게는 전혀 체감할 수 없다. 게다가 대부분의 언어들은 기존의 언어에 객체지향을 얹어놓은 형태기 때문에 굳이 OOP에 맞춰서 짜지 않아도 원하는 결과는 일단 나온다. 이러한 이유들로 인해 학생들에게 C++ 과제를 내주면 C++ 문법을 사용한 C 프로그램인 경우가 태반이다. 이는 Java 같은 언어에서 마찬가지로 나타나는 현상이다. Java 문법이지만 C 프로그램 처럼 짜는 것을 '씨자바'라고 한다. 각 프레임들의 입출력 인터페이스를 설계하고 이벤트 드리븐 방식을 정의한 다음 학생들에게 그에 맞춰 오브젝트를 가공하라고 과제 내주는 게 OOP 과제인데, 현실은 덜렁 몇 줄의 요구사항으로 전체 프로그램 짜 와라가 전부인 게 보통이다. 그러니 학생들이 기껏 몇 백 줄 짜리 코드 짜는 데 procedural 대신 OOP를 사용할 것이라는 건 교수 및 조교들의 망상이다. 자신들도 못 하거나 매우 귀찮아 하는 일을 왜 기껏해야 1-2년 동안 일주일에 3-4시간 교육받은 남에게 시킬까 싶지만 이것이 바로 탁상공론. 그리고 이런 식으로 교육을 하니 소위 노가다꾼밖에 양산이 안 되는 것이다.
의외로 클래스와 객체를 헷갈리는 것도 OOP의 개념을 어렵게 하는 요인. 대개 붕어빵 틀(클래스)과 붕어빵(객체)의 관계로 가르치는 경우가 많다. 하지만 '''사람 - 김연아, 펭귄 - 뽀로로'''이런식으로 property의 유무로 구분하라는 서적도 존재한다. 또한 인스턴스라는 용어와도 헷갈려 하는 경우가 많은데, 인스턴스는 객체를 실체화한 것이라고 보면 된다. 즉 프로그램 코드 상에서 자료형이 임의의 클래스로 선언된 식별자는 '객체'라 하고, 코드 컴파일 후 프로그램이 실행될 때 해당 객체가 메모리에 적재되면 '인스턴스'라고 불린다.[11] 어느 단계를 기준으로 하느냐의 차이일 뿐 객체와 인스턴스는 같은 것이라고 할 수 있다.

6.2. C언어와 객체지향

C언어는 문법적으로 객체 지향을 지원하지 않으나, C언어로 객체 지향적인 구현이 불가능한 것은 아니다. 리눅스 커널을 만든 리누스 토르발스의 말을 들어보자. "you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++." 링크
C를 C++로 확장시키고 최초의 C++ 컴파일러를 만든 비아르네 스트로우스트루프의 경우 처음 컴파일러를 구현할 때 C++를 C 언어로 변환시키는 인터프리터를 통해 만들었다. (물론 현존하는 대부분의 컴파일러는 C++을 C로 바꾸는 작업을 하지 않고 바로 컴파일을 수행한다.) 즉, C로 객체지향 코딩이 가능하다는 말. 스트로우스트루프가 직접 저술한 The C++ Programming Language 책에 해당 내용을 언급한다.
이걸 실용적으로 쓰는 분야도 있다. 임베디드나 펌웨어 관련 프로젝트에서는 여러가지 사정으로 (여러 플랫폼에 포팅 가능해야 한다거나, 툴체인을 지원하지 않는다거나) C언어를 사용하여 큰 규모의 소스코드를 작성해야 할 경우가 많은데 이런 경우에는 객체지향적인 설계를 도입하여야 모듈이나 레이어 사이의 혼잡을 피할 수 있다. 따라서 이런 프로그래머들은 객체지향적인 C의 설계는 반드시 익혀야 할 내용이다.
그러나 타 분야에서는 기술적 탁상공론에 가까운 이야기로, 실용적인 의미가 전혀 없다. "가능하기는 하다"는 것일 뿐 타 객체 지향 언어에 비하면 '''이럴 거면 그냥 쓰지 마''' 수준으로 무지하게 비효율적이고 관리하기도 어렵기 때문에 전혀 의미가 없다. OOP는 좀 더 빠르고 효율적으로 코딩하고 유지 관리를 하자는 이유로 등장한 개념이므로, 본말전도가 되면 무의미하다. 엔지니어링은 기술적으로 가능하더라도 투입 자원 대비 산출 효율을 '''반드시''' 따져봐야 하는 분야다.
일반적인 OOP 언어를 쓰는 것에 비하면,
  • 절차 지향 언어로 객체 지향 설계를 직접 하나 하나 구현해야 하니 프로젝트 진행 기간이 한도 끝도 없이 늘어나고,
  • 이걸 직접 구현할 수 있는 고급 프로그래머를 구하느라 인건비가 추가 지출되며[12],
  • 그렇다고 C언어로 구현된 객체 지향 설계가 진짜배기 객체 지향 언어에 비해 유지/보수하기 쉬울 리도 만무하다.
따라서 인건비를 포함한 프로젝트 유지/관리비가 폭증하게 되는데, 위와 같은 사태를 용납할 클라이언트는 거의 존재하지 않는다.
프로그래밍에서 C언어를 쓰는 경우는 대개 커널이나 라이브러리와 같이 성능이 절대적으로 필요한 경우다. 하지만 이런 곳에서는 객체 지향 설계를 끼워넣어 불필요한 오버헤드를 주는 행위 자체를 지양해야 한다. C언어는 기본 컨셉 "프로그래머를 믿는다"를 따르기 때문에 어떻게 작성하는지에 따라 문제가 일어날 가능성이 매우 높아질 수 있다. 반면 객체 지향은 다소 성능 저하를 감수하더라도 프로그래머가 실수할 여지를 줄여보려는 요소가 곳곳에 산재해 있다. 상극도 이런 상극이 없는 셈.
대부분의 경우에는 굳이 C로 구현해서 쓰기보다는 Java나 C# 같은 고수준 언어를 찾아보는 것이 좋다. ABI(Application Binary Interface)가 필요한 경우가 아니라면 C 같은 저수준 언어는 무의미하다.

7. 관련 문서


[1] 참고로 위 도표는 이런 네임스페이스 포화에 대한 개그이기도 하지만, '''정말로 클래스/메소드/변수 이름을 짓는 게 어렵기 때문에''' 나온 개그이기도 하다. 용도를 잘 표현할 수 있고, (함수의 경우라면) 입력과 출력까지 잘 명시할 수 있으며, 가독성을 해치지 않을 정도로 짧고 간결한 데다가, 거기에 중복까지 회피할 수 있는 이름을 짓는 건 상당한 창작의 고통(…)을 수반하는 일이다. 클래스/메소드 이름만 똑바로 지어놔도 가독성과 유지보수성의 절반 이상은 먹고 들어갈 수 있기 때문에 매우 중요한 일이다. '시작이 반이다'라는 유명한 격언이 괜히 프로그래밍에도 적용되는 게 아니다.[2] "1+2" 라는 수식도 수식으로 보지 않는다. "1"이라는 객체에 "+2"라는 메세지를 보내는것으로 본다. 괄호를 제외한 사칙연산의 순서도 생각하지 않는다. 1+2X2이면, 순서대로 "1"이라는 객체에 "+2","X2"라는 메세지를 보내서 연산할 뿐이다. [3] 단, C++의 경우 이런 동작을 내려면 해당 메소드를 가상 함수로 선언해야 한다.[4] 단, 초기 개발 요구사항 분석단계에서 팀웍이 안 맞거나 정확하게 하지 못하면 망했어요.[5] 잘 만들어진 클래스는 재사용성을 보장한다. Ctrl C+V신공은 나중에 수정사항이 생겼을 때 일일히 찾아서 바꿔줘야 하지만 클래스는 한 곳에서만 바꾸면 끝이다.[6] 구현 목적을 위해 클래스를 나눌 수 있으니 구현 단위와 목표가 뚜렷해진다.[7] 인터페이스를 상속하는데 공통 동작이 있어야 한다면, 결국 할 수 있는건 Ctrl+C Ctrl+V 신공 뿐이다.(...)[8] 이클립스에서 Alt+ Shift + S를 누르면 자동으로 생성해주는 메뉴가 나온다. IntelliJ IDEA는 Alt+Insert를 누르면 Getter와 Setter를 생성하는 팝업 메뉴가 뜬다.[9] ES6부터 클래스 문법이 추가되었다. 프로토타입의 문법적 설탕에 불과하다는 평도 있었으나 프로토타입에 비해 훨씬 더 엄밀한(=실수할 여지를 더 줄이는) 방식으로 프로그래밍해야 되기 때문에 단순히 평가하기는 어렵다.[10] 3.0에서 클래스가 추가되었다.[11] Java는 '객체'를 뜻하는 영단어 Object로 명명된 클래스가 존재하기 때문에, 구분을 위하여 인스턴스라는 표현을 공식적으로 사용하고 있다.[12] 다른 고급 언어와 비교해 C언어가 매우 비생산적인 언어인 탓도 있다.

분류