<div id="readability-page-1" class="page"><div id="site-main" role="main">
 <article>
 
 <figure>
 </figure>
 <section>
 객체지향이라는 말은 어떻게 보면 올드스쿨이다. 함수형 프로그래밍과 대척점에 있어 보이기도 하고, 객체지향 == 자바라고 느껴지기도 하니 말이다. 어떻게 보면 이 책은 그런 생각들이 오해였고, 사실에 대해서 설명해 주는 책이라는 생각이 들었다. 
내가 처음 객체지향이라는 단어를 배웠을 때는 C++ 을 배우면서 절차지향(이 말도 들어본지 꽤 됐다.) 의 대척점에 있는 존재였다. 마치 C vs.C++, 절차지향 vs. 객체지향 같은 느낌. 그래도 힙(hip)한 느낌이었다. 클래스와 캡슐화, 다형성 그리고 예제는 항상 Person 과 Employee 였다. 그 이후로 객체지향이라는 단어는 다음 단계인 디자인패턴(design pattern) 과 effective 시리즈로 나를 이끌었던 것 같다. 
그리고 이 책을 보면서 객체지향에 대해서 다시 생각하게 되었고, 내가 그 동안 클래스를 만들고 책임을 클래스에 할당하고 설계를 하는 등의 일련의 방식들이 조금씩 문제가 있다는 것을 알게 되었다. 지금도 그렇지만 나는 대략 이런식으로 설계를 한다. 
A라는 기능을 하는 프로그램을 개발해야한다. 
<ul>
<li>A라는 기능을 개발을 하기 위해서는 A1, A2, A3 가 필요하다.</li>
<li>그러면 그것들을 약간 추상화(라고 부르기도 애매한)를 해서 클래스를 만들고 suffix 로 manager 를 붙인다.</li>
</ul>
예를 들면, <code>장바구니 기능을 만든다.</code> 라고 생각을 하면 <code>사용자가 선택한 상품을 DB에 저장해야하고</code>, <code>삭제해야하고</code>, <code>수정해야한다</code> 고 생각하고 <code>DBManager</code> 클래스를 만들고 그 안에 <code>add(product)</code>, <code>delete(product)</code>, <code>modify(quantity)</code> 이런 식으로 구성했던 것 같다. 꽤 직관적일 수 있지만 사실 객체지향적인가? 무엇이 객체인가? 하는 생각은 깊게 해보진 않은 것 같다. 
이 책 에서는 무엇이 객체인지 그리고 다양한 객체 지향의 설계 방식에 대해서 잘 설명을 해주고 있다. 객체의 역할도 중요하지만 가장 책에서 중요하다고 반복해서 이야기 하고 있는 것은 협력과 책임 그리고 메시지다. 핵심은 객체 지향에서의 문제해결 방식은 객체들 간의 협력을 통해서 이루어진다고 설명하고 있다. 그리고 이 협력을 위해서 하나의 객체가 다른 객체에게 요청을 함으로써 해당 객체는 그 요청에 대한 <code>책임을 가진다</code> 라고 설명하고 있다. 객체와 객체 간의 책임을 수행하라고 요청 하는 과정을 메시지 전송이라고 정의하고 있다. 
아래에 책에 나왔던 관련 문장들을 곱씹기 위해서 발췌해봤다. 
<blockquote>
객체는 다른 객체와 협력하기 위해서 존재한다.
객체가 적합한지를 결정하는 것은 그 객체의 상태가 아니라 행동이다.
객체 지향 세계에서는 모든 객체가 능동적이고 자율적인 존재다. 
메뉴판은 자기 스스로 메뉴 항목을 찾는다. 
따라서 설계자는 무생물을 생물처럼 의인화 해야 한다.
협력은 요청과 응답으로 구성된다.
어떤 문제에 대한 해결책을 객체 간의 협력을 통해서 만들어 낸다.
객체 지향 설계의 첫번째 목표는 훌륭한 객체를 설계하는 것이 아니라, 
훌륭한 협력을 설계하는 것이다.
협력을 설계할 때는 객체가 메시지를 선택하는 것이 아니라, 
메시지가 객체를 선택하게 해야 한다.
객체가 요청에 대해서 응답할 의무가 있는 경우, 
해당 객체가 해당 요청에 대한 책임을 가진다.
객체는 협력 내에서 정해진 역할을 수행하며, 역할은 관련된 책임의 집합니다.
하나의 객체가 다른 객체에게 주어진 책임을 
수행하라고 요청 하는 것을 메시지 전송이라고 한다.
하나의 책임이 여러 개의 메시지로 분할 된다.
설계 작업은 구현을 위한 스케치를 작성하는 단계지 구현 그 자체 일 수는 없다. 
중요한 것은 설계가 아니라 코드다. 
코드를 통한 피드백 없이 깔끔한 설계를 얻을 수 없다.
</blockquote>
ps) 개인적으로 이 책의 문장들이 너무 좋다.

 </section>
 
 </article>
 </div></div>

ASH84

ash84

객체지향이라는 말은 어떻게 보면 올드스쿨이다. 함수형 프로그래밍과 대척점에 있어 보이기도 하고, 객체지향 == 자바라고 느껴지기도 하니 말이다. 어떻게 보면 이 책은 그런 생각들이 오해였고, 사실에 대해서 설명해 주는 책이라는 생각이 들었다. 
내가 처음 객체지향이라는 단어를 배웠을 때는 C++ 을 배우면서 절차지향(이 말도 들어본지 꽤 됐다.) 의 대척점에 있는 존재였다. 마치 C vs.C++, 절차지향 vs. 객체지향 같은 느낌. 그래도 힙(hip)한 느낌이었다. 클래스와 캡슐화, 다형성 그리고 예제는 항상 Person 과 Employee 였다. 그 이후로 객체지향이라는 단어는 다음 단계인 디자인패턴(design pattern) 과 effective 시리즈로 나를 이끌었던 것 같다. 
그리고 이 책을 보면서 객체지향에 대해서 다시 생각하게 되었고, 내가 그 동안 클래스를 만들고 책임을 클래스에 할당하고 설계를 하는 등의 일련의 방식들이 조금씩 문제가 있다는 것을 알게 되었다. 지금도 그렇지만 나는 대략 이런식으로 설계를 한다. 
A라는 기능을 하는 프로그램을 개발해야한다. 
A라는 기능을 개발을 하기 위해서는 A1, A2, A3 가 필요하다.
그러면 그것들을 약간 추상화(라고 부르기도 애매한)를 해서 클래스를 만들고 suffix 로 manager 를 붙인다.
예를 들면, 장바구니 기능을 만든다. 라고 생각을 하면 사용자가 선택한 상품을 DB에 저장해야하고, 삭제해야하고, 수정해야한다  고 생각하고 DBManager 클래스를 만들고 그 안에 add(product), delete(product), modify(quantity) 이런 식으로 구성했던 것 같다. 꽤 직관적일 수 있지만 사실 객체지향적인가? 무엇이 객체인가? 하는 생각은 깊게 해보진 않은 것 같다. 
이 책 에서는 무엇이 객체인지 그리고 다양한 객체 지향의 설계 방식에 대해서 잘 설명을 해주고 있다. 객체의 역할도 중요하지만 가장 책에서 중요하다고 반복해서 이야기 하고 있는 것은 협력과 책임 그리고 메시지다. 핵심은 객체 지향에서의 문제해결 방식은 객체들 간의 협력을 통해서 이루어진다고 설명하고 있다. 그리고 이 협력을 위해서 하나의 객체가 다른 객체에게 요청을 함으로써 해당 객체는 그 요청에 대한 책임을 가진다 라고 설명하고 있다. 객체와 객체 간의 책임을 수행하라고 요청 하는 과정을 메시지 전송이라고 정의하고 있다. 
아래에 책에 나왔던 관련 문장들을 곱씹기 위해서 발췌해봤다. 
객체는 다른 객체와 협력하기 위해서 존재한다.
객체가 적합한지를 결정하는 것은 그 객체의 상태가 아니라 행동이다.
객체 지향 세계에서는 모든 객체가 능동적이고 자율적인 존재다. 
메뉴판은 자기 스스로 메뉴 항목을 찾는다. 
따라서 설계자는 무생물을 생물처럼 의인화 해야 한다.
협력은 요청과 응답으로 구성된다.
어떤 문제에 대한 해결책을 객체 간의 협력을 통해서 만들어 낸다.
객체 지향 설계의 첫번째 목표는 훌륭한 객체를 설계하는 것이 아니라, 
훌륭한 협력을 설계하는 것이다.
협력을 설계할 때는 객체가 메시지를 선택하는 것이 아니라, 
메시지가 객체를 선택하게 해야 한다.
객체가 요청에 대해서 응답할 의무가 있는 경우, 
해당 객체가 해당 요청에 대한 책임을 가진다.
객체는 협력 내에서 정해진 역할을 수행하며, 역할은 관련된 책임의 집합니다.
하나의 객체가 다른 객체에게 주어진 책임을 
수행하라고 요청 하는 것을 메시지 전송이라고 한다.
하나의 책임이 여러 개의 메시지로 분할 된다.
설계 작업은 구현을 위한 스케치를 작성하는 단계지 구현 그 자체 일 수는 없다. 
중요한 것은 설계가 아니라 코드다. 
코드를 통한 피드백 없이 깔끔한 설계를 얻을 수 없다.
ps) 개인적으로 이 책의 문장들이 너무 좋다.

객체지향 사실과 오해를 읽고.

댓글