이전 포스팅(객체 지향 프로그래밍의 진짜 본질은 무엇인가?)에서는 객체 지향의 개념과 좋은 설계의 방향성을 설명했다. 좋은 설계는 변경과 확장에 대응하기 쉬운 구조를 지향하는 것이고, OOP의 핵심은 메시징(Messaging)이라는 것을 알 수 있었다. 본 포스팅에서는 객체 설계에 더 초점을 맞추어 간결하게 정리한다.
먼저 객체 지향 시스템을 다시 떠올려본다. 객체 지향 시스템은 하나의 시스템을 개별 객체 간의 협력으로 구조화하는 것이다.
학부 2학년 시절, Java 언어 중심의 객체 지향 프로그래밍 강의를 수강했다. 객체 지향 프로그래밍은 현실 세계의 복잡성을 객체라는 관점에서 관찰하여 코드에 투영하는 것이라고 배웠다. 또한 객체 지향의 요소로 캡슐화, 다형성, 추상화, 상속이 있다고 했다. 이 네 가지 개념이 객체 지향을 이루는 근간이라고 배웠다. 잘 이해가 가지 않았고, 개인적으로 학습하며 흔히 알려진 ‘붕어빵-붕어빵 틀’ 비유를 보며 객체와 클래스가 무엇인지 이해하는 듯 했다. 본 수업에서 3-Match Game 게임을 개발하는 프로젝트를 하며 GameBoard, Tile, TileGrid, Timer, MenuPanel, OptionPanel 등 다양한 클래스를 설계했고, 객체 지향 프로그래밍을 잘 수행했다고 착각했다. 이후에도 몇년 동안이나 백엔드 개발을 하면서도 관례적인 Layered Architecture의 Controller, Service, Entity 클래스들을 만들고, DI Framework로 결합도를 낮추기도 하며 좋은 객체 지향 프로그래밍을 하고 있다고 착각했다.
최근에 객체 지향의 요소가 캡슐화, 다형성, 추상화, 상속이 아니라는 글을 보았다. 곧바로 객체 지향 프로그래밍의 요소가 뭔지, 아니 객체 지향 프로그래밍이 뭔지 찾아봤다. 대부분의 결과는 캡상추다, SOLID 원칙, DI 등을 개념적으로만 설명하고 있을 뿐 객체 지향 프로그래밍의 진짜 의미를 포함하지 않았다. 이를 계기로 나는 객체 지향 프로그래밍의 본질과 창시자가 해결하고자 했던 문제점 등을 찾으며 깊게 고민했고, 진짜 객체 지향 프로그래밍이 무엇인지 점점 이해할 수 있었다.
Alan Kay의 이야기를 마음 속에 새기며…
“I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea. The big idea is messaging.”
…
“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.”
2003년 email exchange에서 Alan Kay의 발언 인용
객체 지향을 이해하기 위해 과거로 돌아갔다. OOP의 창시자 Alan Kay는 생물학 전공이었다. 그는 복잡한 생물체를 구성하는 세포로부터 영감 받아 소프트웨어를 구조화하는 방법을 창안했다. 행위를 기준으로 데이터를 조작하는 프로시저 프로그래밍하는 방식인 절차 지향 프로그래밍이 거대한 시스템을 만들기에 적합하지 않다고 생각하여 데이터, 행위를 독립 개체로 엮어 시스템을 구조화하는 방법을 생각해낸 것이다.
