"협력에 참여하는 훌륭한 객체 시민을 양성하기 위한 가장 중요한 덕목은 상태가 아니라 행동에 초점을 맞추는 것이다." - 조영호, 『객체지향의 사실과 오해』, 위키북스(2015), 65p.
클래스는 빵틀, 객체는 붕어빵?
완전히 객체지향을 처음 접하게 될 때 누구나 듣게되는 말이 아닐까?
개발 공부를 처음 시작하고 C 를 배워 절차지향적인 프로그래밍을 하면서 객체지향이란 것도 그냥 C 에 있는 struct 같은 것을 함수랑 같이 묶어놓은 것에 불과한게 아닌가 생각했었다.
하지만 요즘 기술온보딩을 통해 OOP 를 배우고 책을 읽으면서 이런 생각들이 잘못되었음을 알아가고 있다.
온보딩에서 OOP 를 배울때 가장 기억에 남는 부분은 객체로부터 상태를 꺼내 쓰려고 하기보다는 상태를 가진 객체에게 메시지를 보내 처리하도록 해야한다는 점이었다.
이 가이드를 처음 들었을 때에는 굳이 왜 그렇게 해야할까 싶었고, 그래도 가이드가 그렇게 주어졌기에 그렇게 하려고 노력했었다.
역할, 책임 그리고 협력
이 책에서는 객체를 '역할과 책임을 바탕으로 협력하는 자율성을 가진 존재' 로 표현한다.
따라서 객체의 상태는 객체 자신만이 바꿀 수 있어야 하며 외부에서 객체에게 메시지를 보내 책임을 다하도록 요청함으로써 객체들이 협력하게 된다고 얘기한다.
C 의 struct 는 데이터를 담아두는 공간에 불과했지만 객체지향에서의 객체는 스스로 책임을 다하는 생명체와 같다.
그렇기에 객체에서 상태를 강제로 뺏어서 처리하는 것이 아니라 객체가 객체의 역할을 할 수 있도록 메시지를 보내야 했던 것이다.
중요한건 상태가 아니라 행동
이러한 객체지향의 특성을 반영한다면, 객체를 설계할 때 상태를 먼저 생각하는 것이 아니라 행동을 먼저 생각해야 한다고 한다.
클래스를 생각하고, 상태를 생각하고, 그에 맞는 행동을 생각한다면 협력을 위한 객체가 아니라 고립된 객체가 될 가능성이 높으며 재사용성이 낮은 객체가 될 수 있다.
어떤 기능을 위해 어떤 협력을 해야할지, 어떤 행동이 있어야 하며 그 행동을 할 객체가 무엇이고 행동을 하기 위해 어떤 상태가 필요한지 고민하며 접근해야 협력을 위한 객체를 설계할 수 있다.
정리
책을 읽으면서 다양한 부분들을 생각했는데 정리하려니 역시 정리가 잘 안된다.
시간이 없어서 요 며칠새 읽었던 부분을 한꺼번에 적었는데,
역시 하루에 조금씩 나눠서 정리하는게 생각을 더 잘 정리할 수 있을 것 같다.
어쨌든 횡성수설했지만, 오늘의 정리 끝..!
