Software Engineering Note

객체지향의 사실과 오해 (역할, 책임, 협력 관점에서 본 객체지향) 본문

객체지향의 사실과 오해 (역할, 책임, 협력 관점에서 본 객체지향)

devmoons 2015. 11. 22. 16:32


조영호 지음 위키북스 2015.06.17
책소개
객체지향에 대한 선입견을 버려라! 『객체지향의 사실과 오해』는 객체지향이란 무엇인가라는 원론적면서도 다소 위험한 질문에 답하기 위해 쓰여진 책이다. 안타깝게도 많은 사람들이 객체지향의...




같은 회사에 다니는분이 추천하셔서 읽어본 책.


제목 그대로 책체지향에 대해 개발자들이 오해하고 있는 부분들을 집어내고, 어떤것이 좋은 설계인가를 다루는 책이다.


코드가 거의 없는 책이기때문에 개념 위주로 비교적 어렵지않게 읽을 수 있는 책이었다.


특히 이상한 나라의 앨리스를 예로 들면서 이야기에 나오는 부분들을 객체지향 설계 부분과 잘 엮어서 설명하고 있는데


이 부분만 봐도 객체지향에 대해서 얼마나 많은 고찰을 했는지 느껴진다. 단, 반복되는 부분때문에 초반에 다소 지루한 느낌이 들기도 했다.


다음은 머리속에 있는 내용을 대충 정리해본 것


* 클래스는 객체를 표현하기위한 도구일뿐, 클래스가 중심이 아니라 객체가 중심이다.


* 어떤 메시지가 필요한지 생각하고, 그 메시지를 처리할 객체에게 책임을 할당한다.


* 잘 설계된 객체지향 시스템이 꼭 실세계와 동일하다는 이야기가 아니다. 

실생활에서는 수동적으로 사용되는 사물들도 객체들의 세계에서는 자율적인 책임을 갖는다. 그래서 시스템은 실제 세계를 "은유" 할 뿐이다.


* 소프트웨어는 계속 변한다. 좋은 설계란 변경을 고려한 설계다.


* 사용자가 프로그램을 사용하는 대상 분야가 도메인이다. 그리고 도메인을 바로보는 관점을 표현하는 것이 도메인 모델.



1. 도메인을 이해하고, 객체간의 협력을 생각해본다.

2. 도메인 모델을 그려보고, 필요한 메시지가 무엇인지 정한다음에 메시지를 처리할 객체에게 책임을 할당해나간다.

3. 메시지가 정해지면 인터페이스가 정해지고, 모든 책임 할당이 끝나면 구현으로 들어간다.

4. 구현하는 과정에서 변경이 생길 수 있고, 설계가 다시 변경될 수도 있다. 구현과정에서 인터페이스를 흔들지 말아야한다. 

변경의 초점은 메소드와 속성에 맞춰야한다.



'' 카테고리의 다른 글

레거시 코드 활용 전략  (0) 2022.01.09
Functional Thinking (함수형 사고)  (0) 2020.03.23
개발 7년차, 매니저 1일차  (0) 2020.03.08
클린코드  (0) 2017.02.13
소프트웨어 장인  (0) 2016.06.07