책 후기-객체 지향의 사실과 오해

목록

1. 포스팅 개요
2. 정리
3. 생각 및 후기

1. 포스팅 개요

해당 포스팅은 조영호님의 "객체 지향의 사실과 오해" 를 읽고 생각을 정리하기 위한 포스팅이다.

책 내용의 세부적인 내용은 적지 않는다.
(책 다 읽은게 7월 초이다. 정리해야지 해야지 하다가 이제(8월)에 한다.)

그리고 이 책을 읽고 객체지향적인 프로그래밍을 해보기 위해서 커피샵 도메인을 구현해보려고 레포를 만들었다.

해당 사이트는 아래 사이트에 있다.
참고로 깨작깨작 거리긴 했는데, 제대로 고민하고 몰입은 하진 않았다...

순수 자바(POJO)에서 스프링으로 단계적으로 구현을 해보려고 한다.

레포 : https://github.com/SsangSoo/Object-oriented-facts-and-misconceptions

(현재 글쓰는 시점에서 명세를 명확히 할 필요가 있어보읻다..)

2. 정리

객체를 바라볼 때

• 협력 역할 책임 관점으로 보기
• 상태(필드: field)가 아닌 행위(무엇을 할지) 를 생각하며 상태를 정의하기
  • 원래 나는 "이 객체에 어떤 필드(상태)가 필요하지?" 를 생각하고 메서드(행위)를 작성했었다.
• 객체에게 어떤 역할을 부여할지 생각하고, 역할에 따른 책임을 수행할 수 있도록 행동을 정의해야 하겠다.

다형성

• 다형성은 공통된 역할을 여러 객체가 수행할 수 있는 개념이다.
  • 개인적으로는 이 문구가 정말 마음에 들었고, 와닿았다...
• 다형성은 객체들이 주고받는 메시지에 초점을 맞출 때 진가를 발휘한다.

메시지가 중요하다

• 메시지는 다른 객체로부터 메서드를 호출하는 것을 의미한다.
• 객체는 메시지를 통해서 협력한다.
• 애플리케이션을 설계하고 구현할 때 해당 객체의 메시지를 먼저 결정하고 해당 메시지를 수신하여 메시지로부터 야기되는 행동을 책임지고 수행할 객체를 선택해야한다.
  • 객체에게 어떤 역할을 부여할지, 역할에 따른 책임은 무엇인지를 정하고, 그 책임을 어떻게 수행할지 행동을 정의하는 것과 비슷한 맥락이다.

인터페이스

• 인터페이스는 외부와 내부로 나뉜다.
• 외부로 노출되는 인터페이스를 공용 인터페이스라고 한다.

책임

• 책임은 자율적이어야 한다.
  • 어떤 책임을 지는지는 명확해지고, 어떻게 책임을 수행할 것인지는 각 객체의 행동에 달려있다.
  • 협력이 이해하기 쉬워진다.
  • 객체의 외부와 내부의 구분이 명확해진다.
  • 변경에 의한 파급효과를 제한할 수 있다.
  • 유연하게 변경할 수 있는 동시에 다양한 문맥에서 재활용할 수 있게 된다.
  • 적절하게 '추상화되며, '응집도'가 높아지고, '결합도'가 낮아지며, '캡슐화'가 증진되고, '인터페이스와 구현이 명확히 분리되며, 설계의 '유연성'과 '재사용성'이 향상된다.

기억에 남아 메모하고 싶었던 문구

좋은 설계

미래에 대비하는 가장 좋은 방법은 변경을 예측하는 것이 아니라 변경을 수용할 수 있는 선택의 여지를 설계에 마련해 놓는 것이다. 
훌륭한 설계자는 미래에 구체적으로 어떤 변경이 발생할 것인지를 예측하지 않는다. 
단지 언젠가는 변경이 발생할 것이며 아직까지는 그것이 무엇인지 모른다는 사실을 겸허하게 받아들인다. 
좋은 설계는 나중에라도 변경할 수 있는 여지를 남겨 놓는 설계다. 
설계를 하는 목적은 나중에 설계하는 것을 허용하는 것이며, 설계의 일차적인 목표는 변경에 소요되는 비용을 낮추는 것이다.

객체에게 책임을 할당할 때

책임 할당의 기본 원칙은 책임을 수행하는 데 필요한 정보를 가진 객체에게 그 책임을 할당하는 것이기 때문이다. 
이것은 관련된 상태와 행동을 함께 캡슐화하는 자율적인 객체를 낳는다.

도메인 모델

도메인 모델이 안정적인 이유는 도메인 모델을 구성하는 요소가 다음과 같은 특징을 띠기 때문이다.
도메인 모델을 구성하는 개념은 비즈니스가 없어지거나 완전히 개편되지 않는 한 안정적으로 유지된다.
도메인 모델을 구성하는 개념 간의 관계는 비즈니스 규칙을 기반으로 하기 때문에 비즈니스 정책이 크게 변경되지 않는 한 안정적으로 유지된다 


도메인 모델의 이같은 특징은 도메인 모델을 중심으로 객체 구조를 설계하고 유스케이스의 기능을 객체의 책임으로 분배하는 기본적인 객체지향 설계 방식의 유연함을 잘 보여준다. 
비즈니스 정책이나 규칙이 크게 변경되지 않는 한 시스템의 기능이 변경되더라도 객체 간의 관계는 일정하게 유지된다. 
기능적인 요구사항이 변경될 경우 책임과 객체 간의 대응 관계만 수정될 뿐이다. 
이것은 변경에 대한 파급효과를 최소화하고 요구사항 변경에 유연하게 대응할 수 있는 시스템을 구축할 수 있게 한다.

안정적인 도메인 모델을 기반으로 시스템의 기능을 구현하라. 
도메인 모델과 코드를 밀접하게 연관시키기 위해 노력하라. 
그것이 유지보수하기 쉽고 유연한 객체지향 시스 템을 만드는 첫걸음이 될 것이다.

※ 참고로 도메인이란 "소프트웨어로 해결하고자 하는 문제 영역"을 가리킨다.

객체지향의 설계 관점1(마틴 파울러)

개념 관점, 명세 관점, 구현 관점은 동일한 코드를 바라보는 서로 다른 관점이다. 
훌륭한 객체지향 프로그래머는 하나의 클래스 안에 세 가지 관점을 모두 포함하면서도 각 관점에 대응되는 요소를 명확하고 깔끔하게 드러낼 수 있다.


마틴 파울러는 개념적인 관점과 명세 관점 사이는 그렇게 중요하지 않은 경우가 많지만 명세 관점과 구현 관점을 분리하는 것은 매우 중요하다고 주장한다
프로그래머의 입장에서 가장 많이 접하게 되는 것은 코드이므로 구현 관점을 가장 빈번하게 사용하겠지만 실제로 훌륭한 설계를 결정하는 측면은 명세 관점인 객체의 인터페이스다. 
명세 관점이 설계를 주도하게 하면 설계의 품질이 향상될 수 있다는 사실을 기억 하라.

• 명세는 해당 책에서 말하고 있는 책임(인터페이스)과 연관이 깊다.
• 각 관점들은 아래에서 간단히 기술했다.

객체지향의 설계 관점2(마틴 파울러)

객체지향 설계 안에 존재하는 세 가지 상호 연관된 관점에 관해 설명한다.
파울러는 세 가지 관점을 각각 개념 관점, 명세 관점, 구현 관점이라고 부른다.

개념 관점(Conceptual Perspective)

사용자가 도메인을 바라보는 관점을 반영한다. 
따라서 실제 도메인의 규칙과 제약을 최대한 유하사게 반영하는 것이 핵심이다.

명세 관점(Specification Perspective)

객체들의 책임에 초점을 맞추게 된다. 
즉, 객체의 인터페이스를 바라보게 된다.
인터페이스와 구현을 분리하는 것은 훌륭한 객체지향 설계를 낳는 가장 기본적인 원칙이다.

구현 관점(Implementation Perspective)

구현 관점의 초점은 객체들이 책임을 수행하는데 필요한 동작하는 코드를 작성하는 것이다.
프로그래머는 객체의 책임을 '어떻게' 수행할 것인가에 초점을 맞추며 인터페이스를 구현하는 데 필요한 속성과 메서드를 클래스에 추가한다.

클래스

개념 관점, 명세 관점, 구현 관점은 동일한 클래스를 세 가지 다른 방향에서 바라보는 것을 의미한다.
클래스가 은유하는 개념은 도메인 관점을 반영한다. 
클래스의 공용 인터페이스는 명세 관점을 반영한다.
클래스의 속성과 메서드는 구현 관점을 반영한다.

훌륭한 설계

객체지향 설계의 첫 번째 목표는 훌륭한 객체를 설계하는 것이 아니라 훌륭한 협력을 설계하는 것이라는 점을 잊지 말자.
훌륭한 객체는 훌륭한 협력을 설계할 때만 얻을 수 있다.

3. 생각 및 후기

영한님의 스프링 핵심원리 기본편에서 객체지향에 대한 시야가 조금 트였다고 생각했는데, 이 책을 읽고난 후에는 갈 길이 멀구나라는 생각을 하게 되었다.

심지어 이 책은 조영호님이 원래 쓰던 책을 이해를 돕고자 쓰다가 책으로까지 출판되게 되었다고 하였다.

이 책은 "이상한 나라의 엘리스"를 가지고 객체에 대해 이야기를 푼다.
참 절묘하게도 책의 내용과 이 책에서 말하고자 하는 바가 맞아 떨어지는 게 신기했다...

실생활에서의 예를 드는데, 커피숍에 대한 얘기를 든다.

커피 숍에는
바리스타, 주문을 받는 카운터, 고객이 존재한다.

커피숍의 일련의 과정은 다음과 같다.
손님이 카운터에 커피를 주문한다.
카운터는 주문받은 커피를 바리스타에게 제조해달라고 한다.
바리스타는 카운터로부터 주문 받은 커피를 제조한다. 그리고 제조한 커피를 다시 카운터로 건넨다.
카운터는 제조된 커피를 주문한 손님한테 전달한다.

마치 클라이언트와 서버, 객체와 객체간의 요청과 응답의 일련의 과정이 보인다.

다시 기술해보면 다음과 같을 것이다.

손님은 카운터에 커피를 요청한다.
카운터는 손님이 요청한 커피를 바리스타에게 제조하기를 요청한다.
바리스타는 커피 제조에 대한 요청을 받는다. 요청받은 커피를 제조하여 제조된 커피를 카운터에게 건네주며 응답한다.
카운터는 바리스타에게 요청한 커피를 바리스타로부터 응답받고, 손님에게 전달한다.(메서드 리턴이 생각나는 건 나뿐인가...?)
손님은 카운터로에 요청한 커피를 응답받는다.

이처럼 마치 커피숍 도메인에서 일어나는 역할들의 협력은 객체와 객체 간의 요청과 응답의 협력으로도 충분히 표현될 수 있다.

참고로 역할이란
손님, 카운터, 바리스타이다.

그리고 그 역할들은 각자 책임을 가지고 있다.

손님은 커피를 주문할 책임을 가지고 있다.
카운터는 손님에게 커피를 주문받을 책임이 있고 바리스타에게 커피 제조를 요청할 책임이 있다.
바리스타는 카운터가 제조를 요청한 커피를 만들 책임을 가지고 있다.

물론 요즘 바리스타가 주문도 받고 커피도 만들기도 한다.
그럼 카운터 겸 바리스타의 역할을 하는 사람은 주문받을 책임, 커피를 제조할 책임 같은 두 가지의 책임이 있는 것이다.

이러한 하나의 프로세스를 해당 책에서는 협력이라고 표현한다.

영한님은 스프링 핵심원리 기본편에서 로미오와 줄리엣 연극 얘기를 했다.

로미오의 역할을 하는 사람은 김태희가 될 수 도있고, 송혜교가 될 수도 있다.
(무슨 뮤지컬인진 기억이 안 나는데, 그 뮤지컬에 여주의 역할을 맡은 권유리, 박소담, 채수빈이 같이 아는 형님에 나온 적이 있던 거 같다. 하나의 역할을 세 배우가 하는 것이다.)

마찬가지로
손님은 누구인지 모르겠지만, 어쨋든 손님으로 커피숍을 찾은 것이고,
카운터 역시 한 사람만 유일하게 카운터를 하는 것이 아니라, 그 카운터가 퇴사하고 다른 사람이 카운터가 될 수도 있다.
바리스타도 한 사람만 바리스타일 필요가 없다. 파트타임에 따라 다른 바리스타로 대체될 수 있다.

이를 객체지향으로 보게 되면,

역할은 인터페이스이고, 책임은 인터페이스에 정의된 메서드다.
그리고 각각의 역할을 하는 사람은 구현체라고 보면된다.

바리스타 A는 커피에 하트모양을 넣지만, B는 안 넣을 수도 있다. C는 하트가 아니라, 귀여운 곰을 그릴 수도 있다.
각각 어떻게 커피를 제조하는건 바리스타의 재량이지만, 결국 바리스타의 역할을 하는 것처럼

객체도 추상화된 역할을 할 인터페이스가 있고, 각각의 메서드를 어떻게 구현할지는 구현체마다 다르다.
예를 들면 JDBC의 커넥션도 이러한 예로 볼 수 있다.
각 DB마다 커넥션, SQL 전달, 응답을 반환받는 방법이 모두 다른데, JDBC를 이용해서 각각의 DB마다 DB에 접근하는 코드들이 달랐던 것이 추상화되어 JDBC 인터페이스를 이용해서 데이터베이스가 변경되더라도 접근할 수 있게 되었다.

지금까지 적은 내용은 책의 일부에 불과한 내용이다.

먼저는 내가 소프트웨어로 문제를 해결하고자 했을 때 설계시 해당 기능을 수행하고 구현하기 위해서 어떤 협력이 필요할까를 먼저 생각해야겠고, 그 협력에 대해 필요한 역할들은 무엇이고, 그 역할에 대한 책임은 무엇이 있을지 생각하고 고민하고, 객체지향적인 설계를 진행해야겠다고 생각했다.

그리고 글 초반에 쓴 것이지만, 상태(필드, 속성)보단 이 객체가 어떤 행동(메서)이 필요한지를 먼저 고민하고, 그 이후에 상태를 생각하는 방식으로 나아가야겠다.

그리고 기억하고 싶었던 문구에서 좋은 설계는 미래를 예측하는 것이 아니라, 미래를 예측하지 않고, 어떤 변경이 올지는 모르겠지만, 변경은 있을 것이다. 하지만, 객체간의 구조는 바뀌지 않아야한다는 것을 늘 생각하고 프로젝트, 사이드, 토이 프로젝트 등에 적용할 수 있는 훌륭한 프로그래머가 되고싶다...!!