[BOOK : 오브젝트 1장] 객체, 설계를 읽고

대문만들기 어렵네...

최근 블로그와 링크드인을 작성하는 재미에 푹 빠져 살고 있다. 

 

항상 노션으로만 정리를 하였는데 오브젝트를 기점으로 읽고 있는 책들에 대해 하나하나씩 연재를 진행해보고자 한다. 

 

(계속 글도 쓰다보면, 쓰는 능력도 늘겠지란 생각을 가지며) 

 

해당 책은 확실한 이해를 돕기 위해 코드와 함께 설명을 이어간다.

 

코드에 대한 내용은 github에 적고 개인적 견해 및 이론에 대한 내용은 블로그에 적으며 진행하고자 한다. 

 

객체 , 설계 

로버트 글래스는 이론 , 실무 중 어떤 게 먼저일까에 대해 대한 물음에 실무가 먼저라고 이야기했다. 

 

많은 사람들과 당장 개발을 접한지 얼마 안 된 친구들도 이론이 없어서.... 개발 전 이론을 탄탄히 잡고 시작할래라고 말하는 사람들이 대다수였다. 

 

하지만 로버트 글래스는 다음과 같이 이야기했다. 

 

"어떤 분야를 막론하고 이론을 정립할 수 없는 초기에 실무가 먼저 급속한 발전을 이룬다. 실무가 발전하고 난 다음에야 비로소 실무의 실용성을 입증할 수 있는 이론이 서서히 그 모습을 갖춰가기 시작하고, 해당 분야가 충분히 성숙해지는 시점에 이르러서야 이론이 실무를 추월하게 된다. " 

 

맞는 말이다. 아무도 모르는 초기에는 이론이 먼저 절대 올 수가 없다. 이론은 소프트웨어 유지보수에 전혀 관심이 없는 것으로 보인다.

 

결론적으로 이야기하고 싶은건 이 책은 객체지향 프로그램을 설계하고 유지 보수하는데 필요한 원칙과 기법을 설명하기 위해 포커스를 맞춰져 있다. 즉, 실무에 포커스를 맞춰 진행한다. 

 

해당 장에서의 핵심은 로버트 마틴이 말한 이 세가지가 아닐까 하고 생각이 들었다. 

 1. 실행 중에 제대로 동작하는 것 

 2. 목적은 변경을 위해 존재하는것 

 3. 코드를 읽는 사람과 의사소통하는 것 

 

이전 클린 아키텍쳐와 객체지향 사실과 오해를 읽었을 때 동일한 느낌을 받았었다. 

 

해당 챕터의 제목이 객체, 설계인 만큼 나는 읽고 난 후, 다음과 같은 내용으로 요약해 보았다. 

 

결론

1. 변경에 항상 유연한 설계를 진행해야한다. ( 객체 간의 결합도를 느슨하게 ) 

2. 훌륭한 객체설계는 소프트웨어를 구성하는 모든 객체들이 자율적으로 행동하는 설계 

3. 변경 가능한 코드란 이해하기 쉬운코드 

 

캡슐화 등, 이전에 작성했던 내용들에 대한 링크를 첨부한다.

 

캡슐화 

 

캡슐화 예제 깃허브

 

다음은 챕터 2 : 객체지향 프로그래밍에 대해 이야기 해보고자 한다.