객체 지향의 사실과 오해
프로젝트 때문에, SW 트랙 때문에, 변명을 통해 미루고 미뤘던 숙제를 풀었습니다. 책을 통해 조금 넓어진 시야를 정리하려고 합니다.
책을 읽기 전
객체 지향 프로그래밍은 익숙하지만 잘 모르는 영역이었습니다.
들어봐서 아는데 사실 내용은 잘 모르는 것이죠.
객체는 현실에 존재하는 것들을 모방한 것이다.
가장 많이 들었던 객체 지향에 대한 설명이었습니다.
사람이 복잡한 현실을 인지할 때, 단순화하여 보는데
이를 쪼개어 놓은 것을 모방해 옮겨 놓은 것과 같다는 것이었습니다.
하지만 프로젝트를 진행할 때면, 이 정도 지식으로 객체 지향 프로그래밍을 적용한 코드를 작성하기 어려웠습니다.
책을 읽으며
책의 모든 내용이 아니라, 오해 몇 가지 정리하려고 합니다.
모방이 아닌 은유
객체는 현실의 모방이 아니라, 은유를 통한 새로운 창조다.
가장 먼저 깨진 부분입니다. 객체는 현실의 것을 비슷하게 가져다 놓는 것이 아니라, 은유와 같이 이름을 빌려 가져오지만 의미, 내용은 달라집니다.
단순한 예로, 메뉴판을 객체로 가져왔을 때, 현실과 다르게 메뉴판은 수동적이지만 않은 자율적인 객체로 가져오게 됩니다.
역할, 책임, 협력, 그리고 메시지
객체는 자율적입니다. 자율적인 객체가 서로 협력합니다.
객체는 각자의 책임을 가지고 있고, 책임을 통해 역할을 수행합니다.
자율적이라는 의미에서 객체는 다른 객체가 어떻게 동작하는지 상관하지 않습니다. 메시지를 통해 서로 요청과 응답을 주고 받습니다.
이 부분을 이해하면서, 객체 지향에서 DB가 바뀌어도 문제 없이 동작하는 프로그램이 생각났습니다. MongoDB에서 Postgresql 관계형 DB로 바꿀 때, Service 레이어는 Model 레이어의 인터페이스만 알고 있고, 내부의 구현을 생각하지 않습니다. Model의 DB 구현이 교체되어도 Service는 문제 없이 책임을 수행할 수 있습니다.
객체는 특성이 아니라 책임, 행동에 의해서 역할이 나누어진다.
책을 읽고 나서
객체 지향에 있어서 조금은 다른 시야를 갖게 되었습니다.
- 현실의 모방이 아닌 은유를 통한 새로운 창조
- 객체는 특성이 아닌 객체의 행동으로 정의
- 책임을 가진 자율적인 객체가 서로 협력하는 공동체
- 협력의 도구로써 메시지
아직 객체 지향 프로그래밍을 이해했다고 말하기 어렵습니다.
객체 지향의 5원칙, 캡슐화, 다형성, 의존성 주입 등과 같은 내용은 정확히 설명하기 어렵습니다. 프로그래밍 경험이 더 쌓이면 나중에 다시 읽어볼 책으로 남겨두려고 합니다.
