객체 지향 프로그래밍 너의 정체를 드러내라 [객체지향의 사실과 오해]

https://velog.io/@nzlk112/%EA%B0%9D%EC%B2%B4%EC%A7%80%ED%96%A5%EC%9D%98-%EC%82%AC%EC%8B%A4%EA%B3%BC-%EC%98%A4%ED%95%B4

이 책을 읽기 전까지는 내가 객체지향에 대해 잘못 이해하고 있는지 몰랐다.

그리고 객체지향이라며 프로그램을 짰지만, 이 책을 읽고 보니 내가 짠 코드는 객체지향 프로그램이 아니었다.

정말 제대로 객체지향적으로 프로그램을 짜니 훨씬 가독성이 높고, 깔끔하다.

그렇다면 이 책에서 말하는 제대로 된 객체지향은 어떤 것인지 알아보자.

 

객체지향에서 제일 중요한 것은 메시지이다.

객체지향을 강력하게 만드는 비밀은 책임과 메시지에 숨겨져 있다.

객체끼리 어떤 메시지로 협력을 하게 할 것인가를 중심으로 프로그램을 짜면 아주 바람직한 객체지향 프로그램이 탄생한다.

훌륭하고 유지보수가 쉬운 시스템을 만들기 위한 핵심은 모듈 내부의 속성과 행동이 어떤가보다는 모듈이 어떻게 커뮤니케이션하는가에 달려 있다.

훌륭한 객체지향의 세계는 명확하게 정의된 역할과 책임을 지닌 객체들이 상호 협력하는 세계다.

 

사람이 사는 곳이라면 어디서나 역할, 책임, 협력이 존재한다.

프로그램도 마찬가지로 역할 책임 협력을 바탕으로 만들면 조화로운 공동체(애플리케이션)를 만들 수 있다.

역할, 책임, 협력이 객체 지향 프로그래밍의 핵심이다.

각각의 객체는 그 객체가 맡은 역할이 있고, 역할에 따른 책임이 있다.

그리고 그 각각의 다른 책임을 갖고 있는 객체들이 협력하여 큰 프로그램을 만든다.

 

각각의 객체는 다음과 같은 특성을 지닌다.

1. 여러 객체가 동일한 역할을 수행할 수 있다.

2. 같은 역할을 하는 객체끼리는 대체될 수 있다.

3. 각 객체는 책임을 자율적으로 수행한다.

4. 한 객체가 여러 역할을 할 수 있다.

 

각각의 객체는 자율적이어야 효율적인 프로그램을 짤 수 있다.

실생활에서도 사장이 아르바이트생의 모든 일들을 다 관여하려고 하면 자신의 일을 하지 못 할 것이다.

사장은 매니저에게 아르바이트생 관리를 맡기고, 관리를 어떻게 할 지는 매니저가 알아서 한다.

그리고 매니저도 아르바이트생에게 어떤 일을 시켰을 때 하나하나 어떻게 할 지 알려주기보다 무엇을 해야 할 지 알려주고 자율적으로 하게 하는 것이 효율적일 것이다.

즉, 각각의 객체들은 서로 무엇을 할 지는 시킬 수 있어도 어떻게 할 지까지 관여하진 않아야 한다.

따라서 자율적인 객체들은 자신이 갖고 있는 값들(상태)을 스스로 관리해야 한다.

객체는 다른 객체의 상태에 직접 접근할 수도, 변경할 수도 없다.

객체가 다른 객체의 상태를 변경하고 싶다면 메시지를 통해 객체가 스스로의 상태를 바꾸게 하면 된다.

 

객체는 다른 객체와 협력하기 위해 존재한다.

객체지향의 핵심은 클래스가 아니다.

객체지향의 핵심은 적절한 책임을 수행하는 역할 간의 유연하고 견고한 협력 관계를 구축하는 것이다.

또한, 객체 지향 세계에서는 메시지가 유일한 의사 소통 수단이다.

따라서 객체들끼리 어떤 메시지들을 통해 협력을 하게 만들지가 중요하다.

메시지로 상태들이 변경되고, 애플리케이션이 완성된다.

 

사람들은 추상화를 통해 이해하기 쉽게 현실을 분해하고 단순화한다.

'추상화'는 복잡한 것을 단순화하는 것이다.

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=jamsuham75&logNo=220998797138

위 이미지에서 점차 추상화를 하면서 피부표면 등의 불필요한 세부 사항을 제거하고, 중요한 부분만 남겨두고 점점 단순화하는 것을 확인할 수 있다.

 

타입은 개념이다.

따라서 객체들을 개념(타입)을 이용해 분류할 수 있다.

즉, 객체에 특정한 개념을 적용하는 작업이 분류이다.

타입은 객체를 분류하는 기준이고, 타입을 나누는 기준은 객체가 수행하는 행동이다.

 

객체를 결정하는 것은 행동이다.

동일하게 행동하면 동일한 타입이다.

즉, 동일한 타입의 객체들은 동일한 행동을 하는 객체들이다.

다만 동일한 메시지를 객체마다 다르게 처리할 수 있고, 이를 다형성이라고 한다.

새도, 박쥐, 나비도 모두 날지만 각자 나는 방식은 실제로는 다르다.

객체에서 중요한 것은 객체의 행동이다.

따라서 객체를 창조할 때 가장 중요하게 고려해야 하는 것은 객체가 이웃하는 객체와 협력하기 위해 어떤 행동을 해야 할 지 결정하는 것이다.

 

객체지향 설계의 전체적 품질을 결정하는 것은 여러 객체들이 모여 이뤄내는 협력의 품질이다.

개별 객체보다는 객체들의 협력이 더 중요하다.

각각의 객체는 책임을 가지고 있고, 각각의 책임은 여러 메시지로 분할된다.

그리고 메시지들로 협력이 이뤄지기 때문에 결국 메시지들이 객체지향 설계의 핵심이 된다.

필요한 책임과 메시지를 먼저 생각하고, 그 책임과 메시지를 맡을 객체를 만들어줘야한다.

또한 객체가 갖고 있는 상태도 메시지를 수행하는데 필요한 재료일 뿐이므로, 항상 메시지를 우선 시 해야한다.

객체 지향의 핵심은 흔히 생각하는 클래스가 아니고,  객체가 협력 안에서 어떤 책임과 역할을 수행할 것인지, 즉 상호작용을 결정하는 것이다.

 

디자인 패턴은 전문가들이 반복적으로 사용하는 해결 방법을 정의해 놓은 설계 템플릿의 모음이다.

일반적으로 디자인 패턴은 반복적으로 발생하는 문제와 그 문제에 대한 해법의 쌍으로 정의된다.

따라서 디자인 패턴은 유사한 상황에서 반복적으로 적용할 수 있다.

 

TDD도 객체지향 설계 기법 중 하나이다.

TDD는 테스트를 작성하고, 테스트가 돌아가게끔 코드를 작성하고, 코드를 더 낫게 수정하는(리팩토링)의 반복으로 개발해나가는 방식을 말한다.

코드를 작성하기 전에 테스트를 작성한다는 것은 객체들을 어떻게 사용할 지를 코드를 짜기 전에 먼저 생각하는 것이다.

즉 TDD의 핵심은 테스트를 작성하는 것이 아니고 인터페이스를 구현 전에 생각하게 하는 것이다.

인터페이스를 먼저 생각한다는 것은 객체가 어떤 메시지를, 어떤 인자들을 받아서, 어떤 결과를 반환하게 할 지, 즉 어떻게 객체들끼리 상호작용을 하게 할 지를 먼저 생각하게 하는 것이다.

 

핵심 개념을 정리해보자.

메시지

객체가 다른 객체에게 전송하는 요청을 메시지라고 한다.

한 객체가 다른 객체에 접근할 수 있는 유일한 방법이다.

메시지 전송을 통해서만 다른 객체의 책임을 요청할 수 있고, 수신자는 오직 메시지 수신을 통해서만 자신의 책임을 수행할 수 있다.

객체가 제공하는 메시지는 다른 객체가 볼 수 있는 공개된 영역에 해당한다.

메시지는 '어떻게' 수행될 것인지는 명시하지 않는다.

'무엇'이 실행되기를 바라는지만 명시하고, 어떻게 수행될 지는 메시지 수신자에 맡긴다.

각 객체들은 메시지로만 이어져 있다.

따라서 설계의 품질을 높이려면 훌륭한 메시지를 선택해야 한다.

그러기 위해서는 어떤 행위가 필요한지(메시지)를 먼저 결정한 후에 이를 수행할 객체를 결정하자.

다형성

서로 다른 종류의 객체가 동일한 메시지에 대해 다르게 반응하는 것을 말한다.

동일한 메시지를 수신해도 어떻게 수행될 지는 메시지 수신자에게 맡겨지기 때문에 수신자마다 다르게 반응할 수 있고, 이를 다형성이라고 한다.

다형성은 동일한 역할을 수행할 수 있는 객체들 사이의 대체 가능성을 의미한다.

따라서 여러 종류의 객체에 동일한 메시지로 협력할 수 있게 해줘서 객체지향의 유연하고 확장성 있고, 재사용성이 높은 특성을 지원해준다.

인터페이스

일반적으로 인터페이스란 어떤 두 사물이 마주치는 경계에서 서로 상호작용할 수 있게 이어주는 방법이나 장치를 의미한다.

인터페이스의 사용법을 익히기만 하면 내부 작동 방식을 몰라도 쉽게 대상을 조작하거나 의사를 전달할 수 있다.

즉 인터페이스는 내부의 복잡함을 감추고 최소한의 요소만 노출시키는 역할을 해준다.

인터페이스 자체는 바꾸지 않고 내부 작동 방식을 바꾸는 것은 인터페이스 사용자에게 영향을 미치지 않는다.

객체들 또한 인터페이스를 통해 다른 객체와 상호작용한다.

객체는 메시지를 통해서만 상호작용할 수 있기 때문에 인터페이스는 객체가 수신할 수 있는 메시지의 목록으로 구성된다.

객체는 공용 인터페이스만 외부에 드러내고, 이를 통해 다른 객체와 소통한다.

따라서 인터페이스를 바꾸지 않는 이상 내부는 마음껏 수정할 수 있으므로 인터페이스를 통해 객체는 최대한의 자율성이 보장된다.

캡슐화

인터페이스만 외부에 드러내고 외부로부터 구현을 감추는 것을 의미한다.

즉 인터페이스 뒤로 복잡한 것을 숨기는 것을 일컫는다.

따라서 캡슐화를 정보 은닉이라고 부르기도 한다.

데이터와 프로세스를 객체라는 하나의 캡슐 안에 넣어 객체가 자신의 정보를 자율적으로 수정하게 한다는 점에서 객체지향은 캡슐화의 특성을 지닌다.

캡슐화를 통해 두 객체간의 결합도가 낮아지는 효과를 얻을 수 있고, 설계가 유연해지고 재사용성이 높아진다.

도메인 모델

도메인은 사용자가 프로그램을 사용하는 대상 분야이다.

모델은 대상을 단순화해서 표현한 것이다.

따라서 사용자가 프로그램을 사용하는 대상 분야를 필요한 지식만으로 단순화해서 표현한 것이 도메인 모델이다.

또한 도메인 모델은 이해관계자들이 바라보는 멘탈모델이다.

따라서 애플리케이션을 도메인 모델을 기반으로 설계해야 사용자가 도메인을 바라보는 관점을 그대로 코드에 반영할 수 있다.

도메인 모델이 중요한 이유는 여러 이해관계자가 동일한 용어와 동일한 개념으로 의사소통할 수 있게 해주는 도구이기 때문이다.

 

총평

이 책은 객체지향의 핵심은 메시지라는 것을 설명하기 위한 책이다.

이 책은 여러번 읽어야 한다.

이 책은 정말 엄청난 책이다.

하지만, 객체지향을 처음 접한 사람이 읽으면 이해가 되는 부분도 적고, 정말 잘 안 읽힐 것 같다.

이 책은 읽다가 이해가 안된다면 일단 슥 한 눈으로 읽고 한 눈으로 흘리듯 넘기고, 시간이 지난 후 또 읽어보는 것을 추천한다.

객체지향 프로그래밍을 해본 후 또 한 번 읽으면 새롭게 느껴지고, 이해가 되는 부분이 늘어날 것이다.

그리고 자바로 프로그래밍을 하고 자바에 대한 기초가 부족하다면 Do it! 자바 프로그래밍 입문(박은종 저.)를 읽고 이 책을 다시 읽으면 좋을 것 같다.