회사에서 '오브젝트' 책으로 스터디를 시작했습니다.

1장을 읽고 나서 요약과 소감을 간단히 정리했습니다.

이론이 먼저인가? 실무가 먼저인가?

> 실무가 먼저이다. 소프트웨어의 역사가 아직 짧아서 이론이 정립되지 않았기 때문

의인화

> 무생물을 생물처럼 동작하게 하는데에 위화감은 없는가?

설계란 무었일까?

> 설계는 코드를 배치하는 것이다.

좋은 코드란 무엇일까?

> 올바르게 동작해야하고, 변경이 쉬우며, 사람이 읽기 쉬워야 한다.

> - 로버트 마틴 -

> Make it work, then make it beautiful, then if you really, really have to, make it fast.

> - 조 암스트롱 (얼랭의 창시자) -

내가 작성하고 있는 코드는 좋은 코드의 조건을 만족하고 있을까?

올바른 동작, 쉬운 변경, 가독성중에 어떤 것들을 만족하고 있는가?

> 불필요한 의존성 제거, 자율적인 객체, 트레이드 오프

책에서는 예시를 계속해서 개선하고 있다. 나의 코드의 개선점은 무엇이 있을까?

개선이 필요하다면 어떤 식으로 진행할지 생각해보자.

- 무엇을 개선할 것인가

- 어떻게 개선할 것인가

응집도(cohesion)가 높은 객체는 어떤 객체인가?

> 연관된 작업만 하고, 관련이 없는 작업은 다른 객체에게 위임하는 객체

응집도를 높이려면 어떻게 해야할까?

> 객체 스스로 자신의 데이터를 책임져야한다.

절차지향과 객체지향의 근본적인 차이는 무엇일까?

> 책임이 어디에 집중되어 있는가

> 절차지향 - 책임의 소재가 한곳에 몰려있음

> 객체지향 - 각각의 객체들이 책임을 가지고 자신의 일을 한다

설계를 어렵게 만드는 것은 무엇일까?

> 의존성이 많아지면 결합도가 높아지고, 변경이 어려워진다.

> 의존성을 낮추면 응집도가 높아져 객체의 자율성이 올라간다.

설계가 왜 필요한가?

> 요구하는 기능을 온전히 수행하면서, 내일의 변경을 매끄럽게 할 수 있도록 하기 위해

객체지향 설계

> 객체지향은 요구사항 변경에 좀 더 수월하게 대응할 수 있는 가능성을 높여준다

저자의 말에 공감하는가? 객체지향이랍시고 클래스를 엄청 만들어서 더 파악하기 힘들게 만들고 있지는 않은지 돌아보자.

변경이 쉽다 라는 것은 무엇일까?

> 절차지향에 비해 쉽다는 말, 실무에서는 어려운 경우가 많은 것 같다.