그런 개발자들에게 본인의 코드가 객체지향 코드라는 근거가 무엇인지 질문을 해봅니다. 대다수 개발자는 인터페이스 사용 또는 느슨한 결합 방식의 개발을 첫번째로 꼽습니다.
하지만 아쉽게도 이것은 객체지향 코드의 판단 근거가 아닙니다.
객체지향 개발은 개발도구가 캡슐화나 상속, 추상화, 다형성 같은 객체지향의 코드의 형식을 갖출수 있도록 지원해야 합니다. 따라서 현재 대부분의 개발도구는 그냥 사용만해도 코드는 이 형식을 저절로 갖추도록 되어 있습니다. 하지만 객체지향 개발도구를 통해 프로그램을 작성한다고 이것이 객체지향 코드가 되는것은 아닙니다.
이 글을 읽는 독자중에 마이크로소프트 닷넷의 MVC 패턴을 들어보신 분들이 있을것입니다. 클래스를 모델, 뷰, 컨트롤러로 기능적 제한을 두고 그 안에서만 코드를 작성해 프로그램을 완성시켜 나가는 개발모델입니다. 그런데 MVC 패턴은 스몰토크에서 유래합니다. UI가 포함된 프로그램의 최적화 된 개발방식을 정의한것이지요.
그리고 이것이 객체지향 코드 판단의 기준이 되는 클래스의 내용입니다.
객체지향 코드의 최우선적인 조건은 클래스가 기능적인 제한을 두어야 한다는 것입니다.
설명이 좀 부실한가요? MVC를 기준으로 풀어보지요.
MVC는 클래스를 모델, 뷰, 컨트롤러로 제약을 둡니다. 물론 모델과 뷰를 섞어서 코드를 작성해도 됩니다. 하지만 그럴경우 재사용성은 현격하게 떨어집니다. 뷰가 필요없는 코드에서 뷰가 있는 클래스를 상속하거나 참조하기엔 부담이 커지고 참조관련한 제약도 따르겠죠.
반대로 클래스가 기능적인 한정성을 가지고 작성되면 연결점이 많아져 복잡해지는 단점은 있지만 잘게 쪼개진 클래스는 작은만큼 유연하고 사용성도 좋아집니다. 기능이 제한을 갖는다는것은 딱 한곳만 바라본다는 뜻이죠. 즉 색깔이 분명하니 쓰임도 확실합니다.
이런이유로 객체지향 코드라면 클래스는 반드시 기능적인 한정성을 가져야 합니다. 그리고 그 기능은 모델(혹은 데이타), 행위(혹은 컨트롤러), 뷰(혹은 인터페이스) 정도면 충분합니다. 이것들이 섞이게 되면 그것이 촉매가 되어 견고한 객체지향의 고리는 풀리고 구조지향으로 녹아내립니다.
그래서 객체지향과 구조지향을 구별하는 가장 큰 조건은 클래스가 기능적인 한정성을 유지하느냐 하는것입니다. 그리고 만약에 여기에 CBD형식까지 갖춘 코드를 보신다면 제대로 된 객체지향 코드를 보고 있다고 생각하시면 됩니다.
