ThinkAboutSoftware · yoonucho · Mar 23, 2021 · Feb 12, 2021 · Feb 7, 2021 · Mar 5, 2021
diff --git a/Booktalk/Object/FeelsDiscussion1.md b/Booktalk/Object/FeelsDiscussion1.md
@@ -0,0 +1,88 @@
+# Object discussions
+
+## Prologue
+
+### Discussion 1 - Robert W. Floyd
+
+- 프로그래밍 패러다임이라는 용어를 1974년에 Robert W. Floyd가 사용
+- 47년 전에 프로그래밍에도 패러다임이라는 용어를 쓴 분에게 존경을 표하고 싶음
+- 해당 내용에 대한 링크: https://dl.acm.org/doi/10.1145/359138.359140
+- [The Art of Programming](https://en.wikipedia.org/wiki/The_Art_of_Computer_Programming) 의 리뷰어 였다고 함
+- 사실 책 이름에 대해서는 많이 들어봤지만 절판되서 읽을 기회가 없었음. 훗날 절판된 책을 구하거나 한다면 퇴직이나 프로젝트 성 혹은 은퇴 후에나 한번 읽어보면 좋을 것 같다는 생각
+
+### Discussion 2 - Both of two paradigm: procedure and object-oriendted
+
+- [토마스 쿤](https://en.wikipedia.org/wiki/Thomas_Kuhn)의 혁명적인(revolutionary) 패러다임이 프로그래밍 세계에서는 발전적(evolutionary)이라는 저자의 주장에 어느 정도 동의함
+- 왜냐하면 객체지향적인 프로그래밍에 절차지향적인 프로그래밍을 완전히 배제할 수 없기 때문
+- 그래서 패러다임 - paradigm 이라는 단어의 의미를 더 생각해 보게 됨
+- 패러다임이라는 단어가 어떻게 다가왔는지?
+
+#### Scientific revolution
+
+- 여태까지 위키피디아에서 영어 문서보다 뛰어난 한글 문서는 없었는데 토마스쿤의 경우는 한글 문서가 더 뛰어나다는 걸 발견함
+- [토마스 쿤](https://ko.wikipedia.org/wiki/%ED%86%A0%EB%A8%B8%EC%8A%A4_%EC%BF%A4)에서 정상과학과 혁명적 과학이라는 부분이 있는데, 오브젝트 책에서 설명하는 토마스 쿤의 패러다임에 대해 잘 설명하고 있는 부분이라는 게 느껴짐
+- IT 쪽이 아니라 사회과학 쪽이어서 왠지 우리나라 사람이 잘 적어둔 느낌?
+
+### Discussion 3 - No silver bullet
+
+- 튜링상 수상에 빛나는 [프레데릭 브룩스](https://en.wikipedia.org/wiki/Fred_Brooks)의 1987년 논문 [은총알은 없다](https://en.wikipedia.org/wiki/No_Silver_Bullet)가 언급이 되었다
+- 이것이 암시하는 바는 객체지향 패러다임이 정답이고 이게 모든 문제를 해결해 줄 수 있는 것이 아니라는 것을 뜻함
+- 그렇다는 것은?? 저자인 조영호님의 경우 많은 실전 경험과 학문적인 견해를 통해 문제 해결에 정답이 없다는 진리를 깨우쳤을 가능성이 높을 것으로 판단됨, [맨 먼스 미신](https://en.wikipedia.org/wiki/The_Mythical_Man-Month)은 프레데릭 브룩스의 소프트웨어 공학 관련된 매우 유명한 책이고 이 책에 나온 내용을 언급했다는 것은 객체지향 뿐 아니라 소프트웨어 공학에 대해서도 수준 높은 지식을 갖추었을 것으로 생각할 수 있음
+- 여기서도 40~50년 전에 이미 훌륭하신 분들의 논문과 그 방향성에 대해 많은 것을 얘기해 주고 번역서도 나와 있음에도 불구하고 잘 모르고 있는 것이 문제라고 봄. 그렇다고 이런걸 알려줘도 코딩하는 것과 상관 없다고 생각하는 태도가 더 큰 문제일 듯 한데, 어떻게 생각하는지 얘기해 보면 좋겠네요
+
+## Chapter 01
+
+### Discussion 1 - theory and practice
+
+- [로버트 L, 글래스](https://en.wikipedia.org/wiki/Robert_L._Glass)옹을 언급했다, 안타깝게도 내가 아직 읽어보지 않은 책을 언급했지만 이론과 실무 어느것이 먼저인 것인가에 대한 화두는 꽤 좋은 듯 하다.
+- 글에서 저자가 주장하는 바는 추상적인 개념과 이론은 훌륭한 코드를 작성하는데 필요한 도구라고 한다.
+- 사실 소프트웨어는 공학의 레벨이고 컴퓨터 과학과는 거리가 좀 있다는 편을 들어 봤을 때는 충분히 맞는 말이다.
+- 하지만 나는 여기에 덧붙여 본다면 어느 수준 - 그러니까 능숙하게 코드를 작성할 수 있고 그 이상의 좋은 방법을 찾기 시작할 때 쯤 분명 공학적인 방식을 접근하고 이해해야 할 필요가 있으며, 그 때 이론과 더불어 40~50년 전 부터 시작해서 최근까지 잘 만들어 두고 이어져 온 공학 관련된 내용을 배워야할 필요가 있다고 본다.
+- 결국 훌륭한 코드를 작성하는 프로세스는 공학일 테니까, 비전공자도 반드시 알아야 할 것이라고 봅니다 => 문송이지만 공학을 해야 하는 자세 필요
+
+### Discusstion 2 - Problems
+
+- 극장 티켓 판매의 간단한 예제를 통해 실제 클래스 코드를 동반해서 설명한다
+- 그 이후 문제점에 대해 언급하면서 생각할 부분을 얘기해 주는데 이 부분에 대해 잘 이해할 필요가 있다고 본다
+- 객체지향이 반드시 실세계를 완벽하게 모방해야할 필요는 없다고 보지만 상식적인 수준에서의 객체들의 행동에 대해 구현해야 함을 얘기한다.
+- 관람객과 판매원의 수동적인 존재, 객체를 지향함에 있어서 생각해 볼 만한 좋은 소재
+- 또 의존성(dependency) 문제로 class 변경이 다른 class의 의존성으로 인해 변경이 되어야 함을 언급: Audience와 TicketSeller를 변경할 경우 Theater도 함께 변경해야 함
+- dependency, coupling을 우리는 얼마나 이해하고 있는가?
+
+### Discussion 3 - Improved design
+
+- 객체를 자율적인 존재로 변화: 자율적이라는 의미?
+  - message response
+  - interface
+- 객체 사이의 결합도를 낮추고 변경하기 쉬운 코드를 작성하기 위해 따라야 하는 가장 기본적인 설계 원칙 => 이 문장만 읽으면 당연한 얘기처럼 들리지만, 왜 우리의 코드는 이런 설계 원칙을 설명하지 못하는 코드를 작성하는가?
+
+### Discussion 4 - nice?
+
+- 저자는 아래와 같이 언급한다
+
+> 우리는 객체의 자율성을 높이는 방향으로 설계를 개선했다. 그 결과, 이해하기 쉽고 유연한 설계를 얻을 수 있었다. 멋지지 않은가?
+
+- 저자가 이렇게 할 수 있다는게 멋지다고 생각하면 책을 잘못읽은 것
+  - 저자는 당연히 잘 하는 사람이고 객체지향을 잘 아는 사람인데다 책을 써서 알려주는 것이므로 자신의 능력을 자랑? 하는 것으로 볼 수 있는데 그렇지 않다.
+- 자율성이 있는 객체로 설계했고, 이해하기 쉬웠고, 유연한 설계를 했다는 부분 객체지향적인 코드를 작성했다는 이 부분에 포인트가 있어야 함
+
+### Discussion 5 - Object-Oriented Design
+
+- 객체지향 설계에 대한 언급
+- 아직도 설계? 라고 하면 코딩하는 거하고 상관 없는 혹은 어떤 경력이 많은 사람이 해야 하는 고차원적인 행위라고 생각하지만, 내 생각에는 설계를 못하는 프로그래머는 많은 일을 할 수 없다고 자신할 수 있다.
+- 변경을 수용할 수 있는 설계의 의미? 어느 정도까지 생각하고 설계해야 하는가에 대한 의문? => 객체지향의 중요한 의미를 살릴 수 있다면 객체지향적인 설계
+
+## Chapter 02
+
+### Discussion 1 - Requirements
+
+- 객체지향 프로그래밍을 언급하지만 요구사항에 대한 걸 처음 언급한다.
+- 요구사항이란 무엇일까? 요구사항이 뭔지도 모르고 프로그래밍을 한다면 아마 보여주기식 프로그래밍이 될 가능성이 높다.
+- 책에 4페이지에 걸쳐 설명이 되어 있는데, 실제 업무를 하는데 있어서 이해해야 할 중요한 요소라고 봄
+- 이것도 여러 프로젝트를 해 보면 결국 얼마나 말과 글을 이해하는 능력이 좋은지 상식적인 프로세스를 얼마나 잘 이해할 수 있는지로 귀결됨
+
+### Discussion 2 - Trade off
+
+- 교과서적으로만 이해하고 코드를 좀 짜본 거라면 절대 트레이드 오프가 무엇을 의미하는 것인지 모를 것이라고 생각함
+- [객체지향 사고 프로세스](http://aladin.kr/p/HN7Um)라는 책에서도 동일하고 트레이드 오프에 대해 언급을 하고 있고, 상속과 인터페이스의 간극에 대해 유연하면서도 상황에 맞게 사용할 줄 아는 혜안을 가지는게 객체지향 설계의 묘미라고도 하였다.
+- 복잡한 비지니스 프로세스를 여러번 경험하고 나면 이 트레이드 오프가 의미가는 바를 더 잘 알게 될 것이라고 생각하며, 책에서 언급한 내용만으로는 이해할 수 없다고 본다.
diff --git a/Booktalk/Object/YoonusDiscussion2.md b/Booktalk/Object/YoonusDiscussion2.md
@@ -0,0 +1,136 @@
+# Object discussions
+
+
+
+## 들어가며
+
+
+### Discussion 1 - 프롤로그(PROLOG)
+
+프롤로그(PROLOG) - 논리형 패러다임을 수용한 대표적인 언어
+
+논리형 언어라는 단어가 갑자기 생소하게 느껴짐 - 수학적?
+
+그리고 논리형 언어면 컴퓨터가 제일 좋아하는 거 아닐까 하지만 그걸로는 부족하니 객체지향적 언어가 나온거겠지 라는 생각도 들었다.
+
+그리고 프롤로그라고 해서 책의 첫 인사 그 뜻인건가 싶었지만 그건 Prologue였다 ㅎㅎ; 
+
+
+### Discussion 2 - 프로그래밍 패러다임의 수용성
+
+두 패러다임이 함께 존재할 수 있다.
+
+프로그래밍 패러다임은 혁명적(revolutionary)이 아니라 발전적(evolutionary)이다.
+
+무조건적으로 모든 상황에서 객체지향이 최고다가 아니라 필요할 때 쓰는게 중요하구나 싶은 생각이 든다.
+
+그런데 필요한지 아닌지 판단기준은 어떻게 정하는 걸까 
+
+
+
+## 01 객체, 설계
+
+
+### Discussion 3 - 이론이 먼저일까, 실무가 먼저일까? 
+
+로버트 L.글래스(Robert L. Glass) - 이론보다 실무가 먼저다. 
+
+분석이나 설계가 이론이라고 생각을 했었는데 그 이유가 바보같고 어이없지만 코딩을 제외한 문서작성은 이론적인거라고 생각했던거 같다.
+
+하루라도 빨리 객체지향적 프로그래밍을 해보고 싶은 열망?갈망이 생겼다. 조급한 마음도 든다.
+
+
+### Discussion 4 - 의존성의 밸런스는 어떻게 맞춰나가야 하지? 
+
+결합도는 낮춰야 하지만 그렇다고 객체사이에는 없어서는 안되는 의존성 역시나 밸런스조절이 진짜 힘들거 같다.
+
+
+### Discussion 5 - 비록 현실에서는 수동적인 존재라고 하더라도 일단 객체지향의 세계에 들어오면 모든 것이 능동적이고 자율적인 존재로 바뀐다. -의인화
+
+레베카 워프스브록님의 객체를 의인화한다는 표현에서 객체에 대한 애정이 느껴진다고 하면 내가 오버하는 것일까
+
+객체가 생명과 지능을 가진 싱싱한 존재로 다시 태어난다니 나도 체감할 수 있는 날이 오겠지?
+
+
+
+## 03 객체, 설계
+
+
+### Discussion 6 - 어떤 객체도 섬이 아니다[켄트 벡]
+
+객체 세계에는 왕따는 없겠다는 생각이 들어서 이상적으로 느껴진다.
+
+
+### Discussion 7 - 객체가 메시지를 선택하는 것이 아니라 메시지가 객체를 선택한다[Metz12]
+
+이상하다 객체는 자유롭다고 했는데 메시지를 선택할 수 없다라는건  무슨 의미지라는 생각이 들었다.
+그러나 메시지가 객체를 선택해야 하는 이유를 보니 아무리 자유롭다고 해도 최소한의 규칙이 있는거 아닐까라는 생각이 들었다.
+
+
+### Discussion 8 - 객체지향 패러다임에 갓 입문한 사람들이 가장 쉽게 빠지는 실수는 객체의 행동이 아니라 상태에 초점을 맞추는 것이다.
+
+아직 객체지향 프로그래밍을 해본 경험은 없지만 나도 이러할 거 같다라는 생각이 든다. 
+그건 상태관리를 하는 리액트가 생각나서 그런거 같기도 하다.
+
+
+### Discussion 9- 역할은 객체가 참여할 수 있는 일종의 슬롯이다.
+
+개인적으로는 역할이 되게 매력적으로 느껴졌다. 객체가 자유롭다는걸 제대로 와닿게 하는 핵심중 하나라고 할까. 
+
+
+### Discussion 10 - 연극 안에서 배역을 연기하는 배우라는 은유는 협력 안에서 역할을 수행하는 객체라는 관점이 가진 입체적인 측면들을 훌륭하게 담아낸다. 이 부분을 읽고 막연했던 객체에 대해 조금은 이해하게 된거 같다. & 역할은 객체의 페르소나다.
+
+이 부분을 보고 든 생각이 나라는 사람이  상대방의 기준에 따라서 롤이 바뀌는 게 객체가 배역을 연기하는 배우가 되는거와 맥락상 같은게 아닐까 라는 생각이 들었다.
+
+가족들을 예시로 든다면  엄마의 관점에서는 딸일테고 동생들이 보기에는 언니나 누나가 될테고 역할에 맞는 액션을 취하게 되는게 객체와 비슷한게 아닌가라는 생각이 든다.
+
+
+### Discussion 11 - 협력은 연극과 동일하고 코드는 극본과 동일하다.
+
+왠지 낭만적이다 이렇게 비유할 수 있다니! 그러면 개발자는 시나리오 작가인것인가?
+
+
+
+## 04 설계 품질과 트레이드 오프
+
+### Discussion 12
+
+이번 장에서는 데이터 중심의 설계로 코드를 작성하며 나쁜 설계의 예시를 보여준다.
+그러고 언어는 다르지만 나또한 이런식으로 코드를 짜고 있었다는 생각에 뜨끔해진다.
+
+### Discussion 13 - 좋은 설계란 오늘의 기능을 수행하면서 내일의 변경을 수용할 수 있는 설계다.
+
+좋은 설계하면 지금 나에게 떠오르는건 멘토님이 예전에 냥터레스트 서버부분을 리팩토링해주신 코드다.
+
+그당시 객체지향 코드란 이런거구나 라고 감탄은 하였지만 어려워서 감히 merge도 못했는데 지금 다시 보니 
+
+데이터 중심의 내코드가 이렇게 쪼개져서 협력을 하고 있구나 라는 생각이 먼저 들었다.
+
+기존의 내코드는 하나가 변경되면 결합도가 높아서 전체코드를 수정했었는데 멘토님 코드라면 필요한 부분만 수정하면
+
+다른 객체들의 코드를 수정할 일은 없으니 낮은 결합도를 가진거구나라는 생각이 들었다.
+
+또 유지보수를 위한 코드를 만들어야 한다는게 이런 의미구나라는 생각도 들었다.
+
+
+### Discussion 14 - "인터페이스에 대해 프로그래밍하라[GOF94]"
+
+멘토님의 코드를 보면 구현되는 부분은 각각 나누어져 내부에 있으며  다른 객체들과 협력할때는 가지고온 const가 인터페이스역할을 하는거 같다
+이게 내가 맞게 생각하는걸까? 
+
+### Discussion 15 - private으로 설정해도 접근자와 수정자를 통해 속성을 외부로 제공하고 있다면 위반하는 것이다?
+
+private안에 있으면 무조건 캡슐화가 되는거라고 생각했는데 그게 아니라는게 
+
+
+
+### Discussion 16 - 데이터 중심 설계는 객체를 고립시킨채 오퍼레이션을 정의하도록 만든다
+
+내코드는 당연하게도 고립되어 있었겠다 싶어져서 갑자기 코드에게 미안(?)해진다. 앞으로는 객체지향적인 생각을 하도록 의도적으로라도 노력을 해야겠다는 생각이 든다.
+
+
+
+
+
+
+