Docs: Add Chapter 05~07 / SupplementA

[fkdl0048]

중간책은 못 읽었지만, 책을 같이 읽을 수 있어서 너무 좋았습니다. 이런 모임을 만들어주신 종필 님께 감사드리며, 같이 읽고 생각을 나눠주신 분들에게도 감사드립니다..!

14일 온라인 토론은 기말고사로 참여가 어려울 것 같습니다. 가능하다면 꼭 참여하겠습니다!

논의 사항

• 책 이름과 같이 책을 다 읽고 객체지향에 대해서 알게 된 사실과 오해에 대해서 짧게 이야기 해주시면 좋을 것 같습니다.

[github-actions]

우측에 있는 Projects, Milestone, Development를 확인 후 할당 해주세요~! 🙇

[jongfeel]

2024 academic conference에 잘 참여해 주셔서 감사합니다.

아직 학생인데도 객체지향에 대한 이해도가 높아서
내년에도 또 같이 했으면 좋겠습니다.

[jongfeel]

결합도가 높은 예제는 싱글턴 객체의 남용을 생각해 볼 수 있을 것 같습니다.
싱글턴 객체가 순수 함수로만 이뤄져 있다면 상관 없을 수 있고 (그렇다면 싱글턴 객체로 만드는 의미가 없다고 봅니다)
상태를 가지고 있는 순간부터 싱글턴을 참조하는 엄청난 결합도가 우후죽순처럼 퍼지게 되면
리팩터링도 어려운 수준까지 갈 수도 있습니다.

또다른 결합도 예시로는
과도하게 큰 매니저 객체로 볼 수 있는데
책에 얘기한 은유를 빗대서 설명해 보면
관리자는 실무를 해야 하는 사람이 아니고 관리 그 자체를 해야 하는 사람인데
코드에서의 매니저는 관리를 하고 있다기 보다는 실무를 하고 있는 쪽으로 코드가 작성되는 사례가 많습니다.
그러다 보면 필연적으로 다른 객체들의 참조를 많이 하게 되는데
그게 결합도를 높이는 과정으로 이해해볼 수 있을 것 같습니다.

응집도가 낮은 예제는 어떤 한 작업의 흐름이 객체들끼리 모여서 진행되고 있지 않고
전혀 다른 객체들의 도움을 받거나 시키면서 파편화 되는 모습이라고 보고 싶습니다.
저는 이런 현상이 일어나는 이유로 팀원들끼리 설계 리뷰나 코드 리뷰가 제대로 이뤄지지 않고
필요한 대로 비슷한 기능을 구현했을 때 발생하는 문제를 많이 겪어 봤습니다.
모듈이나 패키지 개념을 잘 잡아 두면 나중에 응집도가 낮아지는 일을 크게 막을 수 있다고 봅니다.

[jongfeel]

Pull Request 본문의 논의사항은 코멘트로 추가하겠습니다.

객체지향의 사실과 오해는
소프트웨어 시스템이 동작하는 흐름을
객체들의 협력으로 생각하지 않고
모니터 화면에 보이는 코드의 실행 순서를
클래스 안에 정의한 메서드 정도로 생각하는 것이라고 볼 수 있을 것 같습니다.

이미 "객체지향"이라는 단어에서 객체라는 단어가 드러나 있음에도 불구하고
객체에 대해서 많이 생각하거나 고민하면서 프로그래밍을 하지 않는 것 같습니다.

이건 마치 "디자인 패턴"이라는 단어에서 디자인이라는 단어가 드러내는 의미를 생각하지 않고
구현의 방법에 대해 알고자 하는 자세와 크게 다르지 않다고 봅니다.
(소프트웨어 공학에서 소프트웨어와 공학을 잘 생각하지 않는 것도 마찬가지입니다.)

이런 사실과 오해를 하지 않기 위해서는
그 본질적인 의미를 파악하기 위해 노력해야 하고
그러려면 그 만큼의 시간을 투자하고 이해하려는 자세
그리고 그 지식을 바탕으로 하고 있는 실무나 연구에 드러나게 해야 한다고 봅니다.

[yeslee-v]

정안님의 경험을 들어볼 수 있어서 좋았습니다, 이번 북클럽도 수고 많으셨습니다!

---

전에 잠깐 읽었을 때나 지금이나 여전히 저를 관통하는 한 문장이 있습니다.

'행동이 상태를 결정한다.'

객체지향하면 자연스럽게 '클래스'라는 개념을 떠올렸는데요.

클래스는 그 중 하나일뿐, 결국 객체를 역할, 책임, 협력 세 가지 관점에서 바라보라는 이야기가 가장 와닿았습니다.

[hemil0102]

객체지향 사실과 오해

컴퓨터는 단순히 명령을 통해서 동작하는 기계로 바라보는 관점이 있는가 하면,
애플의 스티브 잡스는 컴퓨터는 마음의 자전거로 비유하기도 했습니다.

알게된 사실은 컴퓨터가 단지 현실 세계의 무언가를 모방해내는 것뿐 아니라 은유를 통해서 새로운 세계를 창조할 수 있다는 것입니다.
가령 현재 개발되는 로봇들도 사람을 닮아 꼭 이족보행일 필요가 없고, 모든 것을 쇠덩어리로 구성할 필요도 없습니다.
무언가 새로운 것을 창조해내는 것, 자연의 원리를 알아가고 잘 조합하는 것이 중요하다는 사실을 알았습니다.

이 책은 개념과 이론으로 컴퓨터 세상을 다르게 바라보는 관점을 제공해주는 필터를 준다는 점에서,
도움이 많이되었으며, 또 컴퓨터를 다르게 바라보는 선언형 패러다임도 있기에,
객체지향만이 프로그램을 만드는 완전한 정답은 아니라는 생각이 듭니다.

선언형이 뜨고 있지만 저는 아직 객체지향을 더 선호하는데 그 이유는 책에 설명 되어있지만,
도메인을 코드로 옮겼을 때 개발자 입장에서는 상태와 행위를 통해서 ...
코드는 길 수 있어도 때론 가독성이 더 나은 것 같습니다.
선언형은 추상화가 더 되었고 캡슐화가 더 되었는데, 조금 상태 파악은 개발자 입장에서도 감춰진 것 같아서..
아직 익숙하진 않습니다.