객체지향이란 실세계를 직접적이고 직관적으로 모델링할 수 있는 패러다임이라고 많이 배운다.
현실 세계에 존재하는 사물에 대한 추상화라는 것인데, 페라리 / 람보르기니 / 포르쉐(나의 드림카)를 자동차라고 추상화하는 것과 같다.
허나 이러한 설명은 철학적인 개념을 설명하는 데엔 적합하지만 객체지향 분석, 설계를 설명하기엔 적합하지 않다.
애플리케이션을 개발하면서 직접 대응되는 실세계의 사물을 발견할 확률은 그다지 높지 않기 때문이다.
화재를 막는 벽과 소프트웨어의 방화벽 굳이 두 개를 연결지어 설명할 필요가 있냐는 뜻인데, 그러지 말고 새로운 세계를 새로운 시각으로 보자는 것이다.
그래도 !! 객체지향을 이해하는 데에 있어 현실 세계와 비유하는 것은 굉장히 학습에 효과적이기 때문에, 한 번 얘기를 하면서 정리하는 식으로 가보자
카페에 도착한 우리, 음료를 주문한다.
"돌체 라떼 레귤러 한 잔 주세용 ^_^"
캐셔는 주문을 접수하고, 바리스타는 커피를 만들기 시작한다.
"꼬동 고객님 주문 하신 돌체 라떼, 단 하나 !! 나왔습니다. >_<"
이제 커피를 먹고 맛있게 먹는다.
이 과정에서 손님, 캐셔, 바리스타 이 세 사람 모두 암묵적으로 협력을 했다. 그리고 각자의 역할을 하며, 그 역할에 책임을 다한다.
소프트웨어 역시 혼자만의 힘으로 해결하기 힘든 복잡성을 가지고 있기 때문에, 위에서 말한 3가지를 지켜야한다.
그 중 협력은 요청과 응답으로 이루어져있다. 그리고 그 요청과 응답을 받은 사람을 객체라고 본다면, 그 객체는 본인의 역할에 책임을 다해야한다.
이렇게 따지고 보면 역할과 책임을 묶어야 하는 것이 아니냐라고 생각할 수 있지만, 둘을 구분지어 생각해보자.
하나의 객체가 하나의 역할을 하는 것은 당연하지만, 다른 객체가 그 역할을 대신 할 수 있으며, 책임에 대해서도 해당 역할을 "어떻게" 수행하는지는 그 객체의 자율성이 보장되어있다.
*커피를 믹스로 만들지, 원두로 만들지는 바티스타의 자율성에 따라 결정된다.
이렇게 생각하면, 둘을 떼고 생각할 수 있을 텐데, 이 관점이 흔히 우리가 알던 "다형성"이다.
자 아까 사람을 객체라고 생각을 했다. 이처럼 요청을 메시지, 요청을 처리하는 방법을 메서드로 바꾸면 ~
평소 수업에서 들은 객체지향의 은유를 떠올릴 수 있을 것이다.
참고로, 메시지와 메서드를 분리하는 것이 객체의 자율성을 높이는 핵심 메커니즘이며, 캡슐화라는 개념과도 깊이 관련되어 있다.
자 그렇다면, 분명 수업에서 "클래스" 얘기도 들었을 것이다. 허나, 클래스가 객체지향의 구성요소인 것은 분명하지만, 핵심을 이루는 중심 개념이라고 말하기엔 무리가 있다.
JS의 경우 프로토타입 기반의 객체지향 언어에서는 객체가 중심적으로 존재하며, 상속 보단 위임을 메커니즘을 기반으로 한다.
그렇다고 클래스가 안 중요하다는 것이 아니고,
훌륭한 객체지향 설계자가 되기 위해 거쳐야 해야하는 것은, 클래스의 관점에서 메시지를 주고 받는 객체의 관점으로 사고의 중심을 전환하는 것이다.
마치 손님, 캐셔, 바리스타끼리 메시지를 주고 받고, 카페를 운용하는거 처럼 말이다.
클래스의 구조와 메서드가 아니라 객체의 역할, 책임, 협력에 집중하고, 객체지향은 객체를 지향하는 것이지, 클래스를 지향하는 것이 아니다 !!
'개발 상식' 카테고리의 다른 글
스터디 첫 모임 (2) | 2021.10.02 |
---|---|
LIS / LIS 역추적 발표 자료(pdf) (0) | 2021.09.29 |
OOP (0) | 2021.03.14 |
Top Down vs Bottom Up (0) | 2020.06.02 |
부동 소수점의 한계 (0) | 2020.03.06 |