지난 포스팅에서 썼듯이 왼쪽 상완골 골절로 인해서 한달 정도를 프로그래밍을 못했다. 그 대신 "객체지향의 사실과 오해" 라는 책을 9월 2일부터 10월 1일까지 한달간 완독하고 나서 내가 배운것들과 알게된것들, 소감을 적어보려 한다.
우선 난 자바의 정석공부할때까지만 해도 왜 객체객체 하는걸까? 객체는 그저 클래스가 붕어빵 기계로 찍어낸 붕어빵에 지나지 않을까? 정도의 인식이 있었다. 물론 세부적인 문법사항들은 다 외우고 어느정도 자바라는 언어의 체계가 머릿속에는 자리잡고 있는 상태였다. 그냥, 단순히 자바라는 언어에 대한 생각만 있고, 그것이 객체지향 패러다임과 어떤 관련이 있을까란 생각이 별로 없었던거 같다.
책에는 일관적으로 강조하는 내용이 있었다.
바로 객체는 자율적으로 주어진 책임을 수행하고, 객체끼리의 협력을 통해 개발자나 사용자가 도메인에대해서 생각하는 기능들이 수행되도록 한다. 만약 누군가가 이 책을 한문장으로 요약하라고 한다면, 난 위와 같이 답할거 같다.
물론 개발자가 생각하는 도메인과, 사용자가 생각하는 도메인은 다를수 있다. 예를들면, 은행원 입장에서 도메인은 고객의 서비스를 제공해주는 곳. 이라면, 고객은 은행이라는 도메인을 예금,적금 등 나의 자산을 불릴수 있는 곳. 이렇게 어떠한 도메인(사용자가 프로그램을 사용하는 대상 분야) 에 대한 추상화된 지식을 도메인 모델이라고 한다.
도널드 노먼이라는 사람은 이렇게 사용자 모델이랑 디자인 모델 이 두개를 최대한 일치시키면 좋은 제품(시스템 이미지)가 나온다고 한다.
객체지향 패러다임은 이 도메인 모델의 세가지 측면을 모두 만족할수있는 유일한 모델링 페러다임이다.
책에서는 객체의 자율성에 대해서 아주 많이 강조했다. 또 그 자율성을 보장하기 위해서는 객체에 할당된 책임이 자율적이어야 한다.
이 책임은 다른 객체에 의해 전달받는 메세지를 통해 결정되는데, 이를테면, "마티니를 만드시오" 라는 메세지와 "보드카를 베이스로 하는 마티니를 만드시고, 젓지말고 흔들어서 주시오" 라는 메세지중에 어떤 것이 객체에 자율적인 책임을 부여할수 있는지 생각해 본다면, 이 책이 강조한 '메세지가 자율적인 책임을 만들고, 유연성을 제공하는 책임이 객체를 자율적으로 만든다' 라는 주장에 동의할것이다. 즉 How 가 아닌 What으로 메세지를 던지면, 간결하고 유연한 설계가 완성된다.
객체끼리의 요청은 메세지를 통해서만 이루어지고, 객체는 외부로 노출되지 않는 부분(캡슐화) 와 외부로 노출되서 다른 객체의 메세지에 반응하고 응답할수 있는 부분(인터페이스) 으로 이루어지는데 외부로 노출된 부분(인터페이스)은 메세지가 정해준다. 즉, 주어진 메세지(요청)을 처리하기 위해서 제공해야하는 메서드나 변수 등을 public으로 두고, 객체의 나머지 부분들은 전부 private으로 둬서 외부에서 접근하지 못하도록 보호한다. 즉, 객체가 메세지를 선택하는 것이 아니라, 메세지가 객체를 선택한다. 객체의 인터페이스는 수신받을수 있는 메세지에 따라 인터페이스가 맞춰지기 때문이다.
나는 책을 통해 다형성 에 대한 객체지향적인 정의도 알게되었다. 그 전까지는 자바의 정석에서 공부한 프로그래밍적 정의인 "조상타입의 래퍼런스로 자손타입의 인스턴스를 참조하는것" 정도로 알고 있었다. 객체지향에서 다형성이란 하나의 객체가 여러가지 타입을 가질수있는 것이다. 자바에서는 이러한 다형성을 조상타입의 래퍼런스가 자손타입의 인스턴스를 참조할수 있게 함으로써, 한 객체가 두가지 이상의 타입을 갖출수 있게 구현한다. 책에서는 또한 다형성이 객체지향에서 어떤 기능을 할수 있는지를 '서로다른 타입의 객체가 동일한 메세지에 대해서 서로 다르게 반응하는 것'이라고 설명했다. 이것을 프로그래밍적 정의랑 연결시켜본다면 이해하기 쉽다. 즉 하나의 객체가 두가지 이상의 타입을 가질수 있으니, 만약 동일한 메세지이더라도, 그 메세지의 타입에 따라서 조상타입의 메서드로 요청에 대한 응답하거나, 자손타입의 메서드로 응답할수 있다는 것이다.
객체의 행동이 상태를 결정한다. 또한 그 행동은 책임으로부터 나온다. 그런데 책임은 그 객체가 어떤 메세지를 수신하는지에 따라 결정된다. 객체의 행동 = 메서드, 객체의 상태 = 객체 내부 속성 으로 생각하면 이해하기 쉽다.
이제는 클래스에 대해 말해보겠다. 클래스란 무엇일까? Class 라는 이름에 어느정도 답이 있다. 바로 "분류" 이다.
우리가 일상생활에서 분류를 할때의 목적을 생각해보면, 클래스의 본질적인 목적에 대해서 어느정도 감이 잡힌다. 우리는 일상생활에서 특정 객체를 개념상으로 추상화하기위해 분류를 한다. 그렇다 개념에 대한 분류를 프로그래밍 적으로구현한 것이 바로 Class 이다. class는 동적인 행동을 지닌 객체들의 '공통된 수행가능한 행동' 을 기준으로 분류한 뒤 정적인 타입으로 추상화 시킨다. 즉 같은 class(개념적 분류)에 속한 객체들은 같은 행동을 수행할수 있고, 또 다른말로는 같은 메세지를 수신할 수 있다. 즉, 같은 책임을 가진다.
이렇게 적절하게 추상화된 타입들은 도메인 모델을 통해서 추후에 코드를 구현할때, 현실세계에 존재하는 사물들을 쉽게 개념적으로 은유할수 있다.
또 인터페이스에 대해서 알게 된 중요한 사실이 있는데, 객체의 인터페이스는 그 객체가 수신할수 있는 메세지에 대한 목록으로 이루어져야 한다. 이게 당연한 것이, 외부로 객체가 상호작용 하기 위한 메서드나 데이터 외에는 굳이 외부로 노출시켜서 사용자가 인터페이스를 이용하는데 혼란을 줄 필요가 없다.
여기서 내가 자바의 정석에서 공부한 Interface의 장점이 나왔다. 바로 독립적인 프로그래밍을 가능하게 한다. 무슨말이냐면, 상호작용하는 객체입장에서는 외부에 노출된 인터페이스만 알고있기 때문에, 객체 내부 구현에 대해서는 몰라도 된다. 즉, 순전히 구현이 아니라 전체적인 코드의 구조에 집중할수 있다.
또한 가장 중요한 점은 '최소 인터페이스' 주의라는 것이 있는데 외부에서 사용할 필요가 없는 인터페이스는 최대한 노출하지 말라는 것이다. 인터페이스를 최소로 유지하면 객체의 내부 동작에 대해 가능한 적은 정보만 외부에 노출 할 수 있다. 그렇다면, 객체지향의 가장 큰 장점인, 객체의 내부를 수정하더라도, 또는 객체의 어떤 데이터를 바꾸더라도, 외부에 미치는 영향을 최소화함으로써 변경과 유지보수에 유연하다.
끝으로 이 책을 읽으며, 가장 와닿았던 문장을 적으며 끝내겠다.
객체에 부여된 책임이 자율적일 수록, 적절하게 '추상화'되며, '응집도'가 높아지고, 객체 간 '결합도'가 낮아지며, '캡슐화'가 증진되고, '인터페이스와 객체내부 구현이 명확히 분리' 되며, 설계의 '유연성'과 '재사용성이 향상된다.
쉽지않은 책이였다. 250 page 정도 되는 이 책을 읽으면서 마치 과거 고3시절 국어 비문학 기술지문을 읽은 느낌을 받았다. 그만큼 나에게는 '객체지향' 에 대한 인식이 없었던거 같다. 그래도 책을 읽는 중간중간에 내가 자바의 정석 공부할때 얻은 지식들이 많이 나오기도 해서 이해하기에는 쉬웠던거 같다. 앞으로 누군가가 나에게 '객체' 나 '클래스', '인터페이스', '다형성' 들을 설명해 보라하면 쉽게 설명할수 있을거 같다.
이책을 읽음으로해서, 단순히 코드나 구현에만 치중했던 나의 스타일이 그래도 객체와 객체의 역할,책임,협력 적인 관점으로 바뀔거 같다.