객체 지향이 무엇이지? 라고 질문하는 것보다
왜 객체 지향을 써야 할까? 라는 질문이 더 도움이 되는 것 같다.
왜 객체 지향을 써야 할까?
좋은 코드를 쓰기 위해서 쓴다!
그렇다면 좋은 코드란?
변경하기 쉽고 이해하기 쉬운 코드이다.
이를 위해 복잡한 프로그램을 작은 단위로 나누고 묶어서 정리해야 한다.
기능을 만들 때에도, 작은 것부터 만들어야 큰 걸 만들 수 있다. (분할 정복 실전편)
이 때 무엇을 기준으로 어떻게 묶어주는가? 이것이 추상화이고 구조화이다.
일종의 분업 구조이다.
한 객체는 다른 객체가 관리하는 데이터를 건드릴 수 없다. 대신 이 객체들은 각자 자기한테 주어진 역할이 있다. 자기가 갖고 있는 데이터와 관련있는 작업만 직접 한다. 연관성이 없는 다른 작업은, 그 작업을 맡고 있는 다른 객체한테 '메세지'를 보내서 맡기게 된다. 메시지를 받은 쪽은 그걸 어떻게 처리할지를 직접 결정할 수 있도록 만들 것이다.
즉, 무엇(What)을 하라는 메시지를 보냈을 뿐, 실제로 어떻게(How) 하라고 지시하는 것은 아니다.
함수 호출이 아니라, '메시지를 통한 소통'이라고 생각해보자
이렇게 하면 변경가능한 데이터를 공유하는 일은 없어지고,
독립된 객체가 서로 메시지를 주고받는 관계만 남는다.
OOP는 메시징, 캡슐화, 동적 바인딩이 합쳐질 때 제일 능률이 높다.
- 캡슐화 : 관련있는 데이터와 프로시져를 찾아서 묶고 다른 객체가 내부를 건드리지 못하게 한다.
- 메시징 : 다른 객체의 데이터나 프로시져가 필요할 때는 메시지를 요청한다. 메시지를 받는 객체는 스스로 처리 방법을 선택한다.
- 동적 바인딩 : 메시지를 받는 객체는 그때그때 달라진다.
이 3가지가 합쳐지면 이런 효과가 나타난다.
1) 변경 가능한 공유 데이터가 최소로 줄어든다
2) 구현 부분(HOW)을 쉽게 바꿀 수 있다.
3) 메시지를 실제로 처리하는 객체를 쉽게 바꿀 수 있다.
객체 지향 프로그래밍이라는 이름과는 다르게도
클래스가 본질이 아니다. 본질은 메시징이다.
이건 독립된 컴퓨터들로 이루어진 인터넷이나 서버-클라이언트 구조로 이루어진 웹의 모습과도 많이 닮아있다.
대기업도, 영화 촬영 현장도, 닮아있는 것 같다!
