객체(Object)란 무엇인가? 회의적인 관점에서.

객체란 무엇인가? 글을 보고 제 생각을 정리하고자 올립니다.

객체란, 객체지향 프로그래밍의 정의(OOP)에 따라서 정의할 수 있다. 일반적인 사전에 나온 OOP는 객체, 클래스, 메시지로 구성된다. 그러면서 추상성, 은닉성, 다형성의 성질을 갖춘다. 요즈음 들어서 나는 이 정의가 맞지 않는 경우를 많이 겪었다. 그래서 회의적으로 바라볼 수 밖에 없다. 기존 객체 지향 프로그래밍의 전통에 대한 회의적인 나의 생각을 정리해보았다.


1. 클래스가 필수적인가?

객체지향 프로그래밍은 클래스를 필수적인 요소로 정의하고 있다. 하지만 클래스가 없이도 객체를 충분히 정의할 수 있다. 파이썬에서는 다음과 같은 코드가 동작한다. 클래스가 없이도 객체에 메서드와 변수가 정의된다. 언어가 워낙에 동적인데다 리플렉션을 잘 활용하고 있어서 가능하다. 파이썬의 이러한 특성은 클래스가 필수적인 언어보다 전략, 상태 패턴을 구현하기 훨씬 쉽게 만들어준다. Java와 C# 등의 언어에서 전략, 상태 패턴은 구현하기에 매우 복잡하고 어렵다.

>> o = Object()
>> o.text = "text"
>> def printTest(self):
... print self.text
>> o.print = printTest
>> o.print()
text


2. 레퍼런스가 필수적인가?

많은 사람들이 자바와 C++을 처음에 배우면서 객체와 레퍼런스를 많이 헷갈리곤 한다. 그래서 레퍼런스가 없이는 객체를 활용할 수 없다고 믿는 사람들도 있다. 하지만 레퍼런스 없이 인스턴스만으로 사용할 수도 있다. C#에서는 구조체(struct)에 클래스처럼 메서드를 구현할 수 있다. 하지만 클래스와는 확실히 구분된다. 레퍼런스가 아닌 값에 의한 복사가 된다. 일반 객체와는 달리, 일반 변수처럼 자신의 스코프를 벗어나면 메모리에서 바로 없어진다. 이것을 객체로 보아야 하나, 말아야 하나? 기본적인 정의에는 벗어나지 않으므로 객체로 볼 수 있다.

struct Color{
private String Name;
public String Name{set{this.name = value;} get{return this.name;}}
}

Color red;
red.Name = "Red"; // 객체를 생성하지도 않았는데 작동한다.
Color blue = new Color(); // 객체처럼 생성할 수도 있다.
blue = red; // 레퍼런스가 아닌, 내부 값을 복사한다.
blue.Name = "Blue"; // 레퍼런스라면 red도 이름이 바뀌어야 하지만 struct는 바뀌지 않는다.
Console.WriteLine(red.Name); // Red 출력
Console.WriteLine(blue.Name); // Blue 출력


3. new Class() 와 같은 생성자가 꼭 필요한가?

기존의 C++, Java, C#, VB.NET 등의 언어에서는 new Class() 스타일의 생성자를 써왔다. 그래서 GUI 모양이나 데이터베이스 드라이버와 같이 실행 환경에 따라 구현이 바뀔 수 있는 클래스에 대해서는 복잡하고 어려운 팩토리 패턴을 쓸 수 밖에 없었다. 하지만 루비와 같은 몇몇 언어에서는 Class.new() 방식의 생성자를 사용한다. 따라서 팩토리 패턴을 대거 생략할 수 있다.


4. 예가 너무 어렵다. 간단한 예는 없나?

은닉성을 너무 강조하면 세부 사항을 알 수가 없다. 그러면 디버깅은 매우 힘들다. C#, 자바 등의 언어는 이 한계를 극복하기 위하여(물론 다른 용도를 위해서도) 리플렉션을 지원한다. 또한, 어설픈 다형성은 보안 문제와 각종 호환성 문제의 원인이 된다. 그래서 자바와 C#에서는 다형성을 막기 위해 한정자를 적절히 쓰는 것이 중요하다.


5. 그러면 무엇이 필수적인가?

가장 넓은 정의로, 객체는 자료와 함수를 묶어놓은 것이다. 이 이외의 모든 정의는 부차적이다.


클래스와 다형성, 추상성, 은닉성 등의 특징은 분명히 갖추면 좋은 틀이다. 하지만 이러한 특징이 문제를 푸는 데에 제약으로 작용하는 경우가 가끔 있다. 그리고 최근 개발 환경은 이러한 제약에서 벗어날 수 있는 방법을 하나 둘 갖추기 시작했다. 따라서 항상 기존 방법에 대하여 회의적으로 생각하고 현재 환경에서 가능한 돌파구를 찾아보는 것이 한층 더 뛰어난 개발자로 가는 길이리라 생각한다.


이 글을 다 쓸 무렵, 관련있는 글을 구글에서 찾았다. 나는 이 의견에 완전히 동의한다.
객체지향 프로그래밍에 대한 오해와 진실