객체지향사고프로세스 - MATT WEISFELD, 제이펍

프로그래밍보다 먼저 익혀야 하는 생각의 기술

0. 서평의 기회

서평을 할 기회가 왔습니다. (현재 기준 3년 정도되는 블로그 역사에서 첫 서평입니다.)

제이펍이라는 출판사에서 제공하는 이벤트에서 당첨되어 책을 받아볼 수 있게 되었습니다.

먼저 이 글을 쓰고 있는 필자는 2020년 현재 3년차 자바 개발자고, 조영호님의 저서 객체지향의 사실과 오해 라는 책을 1회 읽어본 적이 있습니다. (https://jeong-pro.tistory.com/189)

"객체지향사고프로세스" 라는 책 또한 넓게 봤을 때 객체 지향이라는 개념적인 주제 를 다루기 때문에 저의 지식 수준을 미리 알려드립니다.

책을 읽기 전...

"객체지향"이라는 주제는 한 두 번 읽고 이해하고 끝나는 주제가 아니라고 생각합니다.

항상 곁에 두고 볼 필요가 있고, 한 번 볼 때마다 1~2개의 아이템만이라도 내 것으로 만들면 성공이라고 생각합니다. (ex. effective java, 객체지향의 사실과 오해, 오브젝트, GoF의 디자인패턴, ...)

그 만큼 심오한 주제를 어떻게 초보자가 볼 수 있게 했을까 궁금하기도 하고 (객체지향 사고(思考) 프로세스 라고 하길래) + 3년 차때 보는 객체지향의 의미는 어떨까 궁금해하며 책을 보게 되었습니다.

그 외에 부제목에 대해 비판적인 개인 생각도 있었습니다.

프로그래밍보다 먹저 익혀야 하는 생각의 기술...?

앞서 언급했듯 현직자도 여러번 읽고 또 읽으면서 조금씩 이해하는게 일반적인데? 하는 우려가 있었습니다. (객체 지향으로 생각하는 것이 중요하긴 합니다만...)

대략 이정도로 인지하시고 자세한 건 밑에서 정리하도록 하겠습니다.

포스트 구성은 장점, 단점, 총평으로 나누어서 말씀드릴 것이니 참고하시기 바랍니다.

1. 장점

• 옮긴이(번역자)의 조심스러움과 철학이 있음
  • 지식보단 개념에 대한 서적이라 용어 하나에도 노력이 있음
  • 베타리더의 의견도 꼼꼼하게 첨부해주었음
  • 저자의 의도를 왜곡하지 않으려는 노력이 있음
• 270쪽의 짧은 구성
  • 객체지향에 대해 어느정도 이해하고 있는 사람의 경우, 술술 읽고 넘어갈 수 있음
  • 이해 안되는 부분을 억지로 머리 쥐어짜며 할 것 까지는 없는 구성
• 상속에 대해서 예시를 통해 적용해보면서 간접 경험할 수 있음
  • 상속을 써야할지 인터페이스를 써야할지 고민하고 공통점을 추상화할 때 잘못된 사례를 볼 수 있음
• 객체지향을 이루는 개념들을 학습하면서 자연스럽게 디자인패턴으로 연결시켰음
  • 모범 사례(best practice)를 통해 객체지향에 익숙해질 수 있게 했음 (물론 디자인패턴을 다루는 책은 아니라서 간단한 소개지만 사고 또는 의식의 흐름으로 연결됨)

2. 단점

• 쉬운 난이도는 아님
  • 절대 초보자가 볼 책이 아님, 특히 프로그래밍에 대한 이해없이는 접근하기 어려움, 그렇다고 오브젝트(조영호님이 쓴 책)와 같은 중급자가 볼 책도 아님...
• 프로그래밍 예시가 자바코드도 아니고 의사코드(pseudocode)도 아닌 듯한 난해함
• 번역이 실무에서 쓰는 용어로 반영하려고 노력했지만, 개인적으로 잘 안 쓰는 용어라 어색한 것도 있었음 (의존소, 추상소, ...)

3. 정리와 느낀점, 총평

정리

• 고전적인 객체지향
  • 캡슐화(encapsulation) : 데이터와 행위(메소드)를 단일 객체로 만들고 데이터를 조작하는 것은 객체가 메소드를 통해서만 할 수 있게 한다.
  • 상속(inheritance) : 클래스에서 다른 클래스를 상속하고 슈퍼클래스에서 정의된 속성과 메서드를 재사용하게 한다.
  • 다형성(polymorphism) : 비슷한 객체가 다른 방식으로 동일한 메세지에 응답하는 것이다. (인터페이스 구현)
  • 합성(composition) : 어떤 한 객체가 이 객체와 다른 여러 객체를 멤버 변수로 두고 사용하는 것을 의미한다.
• 좋은 인터페이스란 무엇인가?
  • 올바르게 설계된 경우, 구현부가 변경되어도 사용자 코드는 변경되지 않아야 한다. (인터페이스를 호출하는 부분은 메소드 시그니처가 바뀌지 않는 한 고정)
• 가능한한 사용자 인터페이스를 줄이자
  • 사용자 인터페이스를 많이 제공하면 사용자가 사용하는 부분이 많아져 추후에 변경에 난해할 수 있다.
• 네이티브 코드 추상화하기
• 변수의 범위는 가능한 한 작게 유지하기
  • 변수의 변경이 예측 가능하려면 메서드 단위에서 사용해야하고 사용 블럭 범위도 최소화시켜야 한다.
• 상속(Inheritance) vs 합성(Composition)
  • 클래스 재사용이라는 측면에서 어떤 것이 더 객체지향적이고 유지 보수하기 좋은 방법일까에 대한 논쟁이 계속되고 있다.
  • 개인적인 생각으로 합성을 쓰는게 낫다는 생각입니다. 상속이 꼭 필요한지 오랫동안 고민하고 합성보다 적절하고 변경 가능성이 없는지 생각해봐야 한다고 생각합니다. (어설프게 상속썼던 부분을 수정하다가 엄청 힘들어졌던 경험이 있음...)
• 상속이 캡슐화를 약화시킬 수 있다.
  • 상속이 객체지향적인 방법이긴 하나, 슈퍼클래스와 서브클래스간에 캡슐화는 오히려 약해지고, 심지어 슈퍼클래스의 변경이 서브클래스들에게 엄청난 파급효과를 만들 수 있는 문제가 있음
• 프레임워크(Framework)가 제공하는 표준 인터페이스를 따라보자
  • 프레임워크가 제공하는 것들을 사용하는 것이 객체지향의 관점에서 코드 재사용일 수 있다.
• 안정적인 시스템에 대해서...
  • 복잡하지만 안정적인 시스템은 보통 위계구조라는 형태를 취하는데, 각 시스템은 더 단순한 하부 시스템을 사용해 구축되며, 각 하부 시스템은 또 그보다 더 단순한 하부 시스템으로 부터 구축된다. (모듈화라 보면 될 듯하다, 독립적인 하위 시스템이 상위 시스템을 구성한다)
  • 거의다 분해해볼 수 있다. (분해가 쉽게 가능할 정도로 독립적으로 잘 나눴다는 얘기같다)
  • 거의 항상 서로 다른 조합으로 배열된 몇 가지 종류의 하부시스템으로만 합성된다.
  • 안정적인 시스템은 거의 항상 작동해왔던 단순한 시스템에서 발전했다.
• 디자인 패턴의 네 가지 요소
  • 패턴 이름 : 한두 단어로 설명 가능해야 함
  • 문제 : 패턴을 적용할 시점, 사례를 설명 가능해야 함
  • 해법 : 설계, 관계, 책임, 협업을 이루는 요소로 어떻게 문제를 해결하는지 설명 가능해야 함
  • 귀결 : 해법을 적용했을 때 생기는 이슈와 절충점 (시공간상 절충, 이식성, 확장성, 유연성, ...)

느낀점

이 책을 읽고 난 후에 드는 느낌은 중구난방으로 퍼져있던 객체지향에 대한 지식들이 하나의 큰 흐름으로 맞춰지는 듯한 느낌이었습니다.

디자인패턴이나 상속, 캡슐화, 인터페이스, 다형성, 합성 등... 항목별로는 어느정도는 설명할 수 있을 정도로 알고 있었지만, 이런 지식들이 모여서 하나의 객체지향적인 사고, 객체지향적인 코드를 작성하려는 노력으로 귀결되지는 않았던 것 같습니다.

근데 이 책을 읽고 어느 정도 정리가 된 느낌입니다.

대신 모르던 것, 새로 알게 된 것, 새로운 견해(?)를 보고 느끼는 어떤 인사이트는 없었습니다...

총평

객체지향 사고 프로세스라기엔 조금 기대한 것 보다는 약했던 것 같지만, 객체지향의 개념에 대해서 가볍게 정리하기에 좋은 책이라고 생각합니다.

가볍게 읽고 정리하고 디자인패턴이라든지 좀 더 객체지향적인 코드를 짜봐야겠다는 동기부여가 되는 책입니다.