From bc3fddc6d223cc17b5e2c4fc6ff63f2cfed50682 Mon Sep 17 00:00:00 2001 From: yoonucho Date: Fri, 12 Feb 2021 13:53:59 +0900 Subject: [PATCH 1/3] =?UTF-8?q?Objects=2002=20=EA=B0=9D=EC=B2=B4=EC=A7=80?= =?UTF-8?q?=ED=96=A5=20=ED=94=84=EB=A1=9C=EA=B7=B8=EB=9E=98=EB=B0=8D=20Rev?= =?UTF-8?q?iew?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Booktalk/Object/YoonusReview.md | 283 ++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 Booktalk/Object/YoonusReview.md diff --git a/Booktalk/Object/YoonusReview.md b/Booktalk/Object/YoonusReview.md new file mode 100644 index 0000000..9c384ab --- /dev/null +++ b/Booktalk/Object/YoonusReview.md @@ -0,0 +1,283 @@ +# 오브젝트 - 코드로 이해하는 객체지향 설계 + + +## 이 책을 읽게 된 계기 + +- 이책의 존재에 대하여는 youtube 코딩의 신 아샬님의 채널([https://www.youtube.com/watch?v=PX_Ot_irSG8](https://www.youtube.com/watch?v=PX_Ot_irSG8))을 통하여 작년부터 알고 있었는데 당시에는 뽐뿌가 오지 않아서 기억만 해두었다가 저자 조영호님의 객체지향의 사실과 오해를 멘토님의 추천을 통하여 읽고 나서야 오브젝트도 조영호님이 쓰신 책이라는 사실을 알게 되어서 바로 구입을 하여 읽기 시작하게 되었습니다. + + + +## 과거 객체지향에 대한 생각 + +- 9년전에 자바&오라클을 3개월정도 배운적이 있었습니다. + +- 당시에 오라클 강사님이 객체지향은 붕어와 붕어빵틀의 관계같은거라고 설명해주셨었고 이후 객체지향이라는 단어를 듣거나 보면 붕어빵과 붕어빵틀을 자연스레 떠올리게 되었습니다. + +- 하지만 멘토님의 멘토링과 객체지향의 사실과 오해라는 책을 읽고 객체지향이란 무엇인지 궁금하고 고민하게 되었습니다. + + + +## 02 객체지향 프로그래밍 + +- 저자는 이번 장의 목표는 이 책을 읽으면서 이해하게 될 다양한 주제들을 가볍게 살펴보는 것(얉은 수준이라도)이다라고 얘기합니다. + +- 이 책을 읽기 위해 필요한 가장 중요한 준비물은 가벼운 마음가짐이라는데 과연 어떨까요 + + + + + +### 02 객체지향 프로그래밍을 향해 + +#### 협력, 객체, 클래스 + +객체지향의 본질은 클래스가 아닌 객체에 초점을 맞춰야 하며 이를 위해서는 프로그래밍을 하는 동안 집중해야 할 두가지가 있습니다. + +1. 어떤 클래스가 필요한지를 고민하기 전에 어떤 객체들이 필요한지 고민하라. +2. 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 일원으로 봐야한다. + + +#### 도메인의 구조를 따르는 프로그램 구조 + +- 사용자가 원하는 어떤 문제를 해결하기 위해 사용자가 프로그램을 사용하는 분야를 **도메인**이라고 부른다고 합니다. + +- 제가 웹세계로 알고 있는 도메인이라는 용어는 ip주소를 식별하게 만든 인터넷 주소인데 제가 알고있는 도메인의 범위는 도메인 용어의 극히 일부겠구나라는 생각이 들었습니다. + +- 요구사항과 프로그램을 객체라는 동일한 관점에 바라 본다라는게 머리로는 조금 이해하겠지만 솔직히 직접 와닿지는 않는데 객체지향 프로그래밍의 경험이 없어서 그런거 같습니다. 😅 + +#### 클래스 구현하기 + +- Screening 클래스는 사용자들이 예매하는 대상인 상영을 구현하고 +- Screening은 상영할 영화(movie), 순번(sequence), 상영 시작 시간(whenScreened)을 인스턴스 변수로 포함합니다. +- Screening은 상영 시작 시간을 반환하는 getStartTime 메서드, 순번의 일치 여부를 검사하는 isSequence 메서드, 기본요금을 반환하는 getMovieFee 메서드를 포함합니다. + +구현된 코드 + +```java +Public class Screening { + private Movie movie; + private int sequence; + private LocalDateTime whenScreened; + + public Screening(Movie movie, int sequence, LocalDateTime whenScreened) { + this.movie = movie; + this.sequence = sequence; + this.whenScreened = whenScreened; + + } + + public LocalDateTime getStartTime () { + return whenScreened; + } + + public boolean isSequence (int sequence) { + return this.sequence == sequence; + } + + public Money getMovieFee () { + return movie.getFee(); + } +} +``` + +- 인스턴스 변수는 private로 메서드는 public으로 지정한 거처럼 내부와 외부를 구분하여 접근성을 제어하는 이유는 경계의 명확성이 객체의 자율성을 보장하기 때문이라고 합니다. 그리고 더 중요한 이유로 프로그래머에게 구현의 자유를 제공하기 때문이라고 합니다. + + **자율적인 객체** + + 1. 객체는 상태(state)와 행동(behavior)을 함께 가지는 복합적인 존재 + 2. 객체가 스스로 판단하고 행동하는 자율적인 존재 + +- 객체 지향은 객체라는 단위 안에 데이터와 기능을 한 덩어리로 묶음으로써 문제영역의 아이디어를 적절하게 표현할 수 있게 했는데 이처럼 데이터와 기능을 객체 내부로 함께 묶는 것을 **캡슐화**라고 부릅니다. + +- 외부에서의 접근을 통제할 수 있는 접근 제어(access control) 메커니즘도 함께 제공하는데 public, protected, private과 같은 접근 수정자(access modifier)를 제공합니다. + +- 캡슐화와 접근 제어는 객체를 두부분으로 나누는데 하나는 접근 가능한 부분으로 퍼블릭 인터페이스(public interface)라고 부릅니다. + +- 다른 하나는 외부에서는 접근 가능하고 오직 내부에서만 접근 가능한 부분으로 이를 구현(implementation)이라고 부릅니다. 인터페이스와 구현의 분리(separation of interface and implementation) 원칙은 훌륭한 객체지향 프로그래밍을 만들기 위해 따라야 하는 핵심 원칙입니다. + + + **프로그래머의 자유** + +- > 프로그래머의 역할을 클래스 작성자(class creator)와 클라이언트 프로그래머(client programmer)로 구분하는 것이 유용합니다. [Eckel06] + + +- 이 내용은 2006년도에 쓴 Thinking in Java에서 나오는 인용구이며 저자는 브루스 에켈이라는 분입니다. + + +![화면 캡처 2021-02-11 182413](https://user-images.githubusercontent.com/2981954/107627040-09cf1480-6ca2-11eb-84ca-81dce4586eff.jpg) + +- 그런데 클래스 작성자는 구체적으로 어떤 포지션을 말하는 건지 잘 모르겠습니다. + +- 클래스 작성자는 클라이언트 프로그래머가 숨겨 놓은 부분에 마음대로 접근할 수 없도록 방지함으로써 클라이언트 프로그래머에 대한 영향을 걱정하지 않고도 내부 구현을 마음대로 변경할 수 있는걸 **구현은닉**이라고 부릅니다. + +#### 협력하는 객체들의 공동체 + +- 시스템의 어떤 기능을 구현하기 위해 객체들 사이에 이뤄지는 상호작용을 **협력**이라고 부릅니다. + +#### 협력에 관한 짧은 이야기 + +- 수신된 메시지를 처리하기 위한 자신만의 방법을 **메서드(method)**라고 부릅니다. + +- 메서드와 메서드를 명확하게 구분한 것 -> 객체지향 패러다임이 유연하고, 확장 가능하며, 재사용 가능한 설계 + + + +### 03 할인 요금 구하기 + + + +#### 할인 정책과 할인 조건 + +**TEMPLATE METHOD 패턴(GOF94)** + +- 부모클래스에 기본적인 알고리즘의 흐름을 구현하고 중간에 필요한 처리를 자식 클래스에게 위임하는 디자인 패턴 + +**오버라이딩과 오버로딩** + +> 많은 사람들이 오버라이딩(overriding)과 오버로딩(overloading)의 개념을 혼동한다. 오버라이딩은 부모 클래스에 정의된 같은 이름, 같은 파라미터 목록을 가진 메서스를 자식 클래스에서 재정의하는 경우를 가리킨다. + +> 자식 클래스의 메서드는 오버라이딩한 부모 클래스의 메서드를 가리기 때문에 외부에서는 부모클래스의 메서드가 보이지 않는다. +오버로딩은 메서드의 이름은 같지만 제공되는 파라미터의 목록이 다르다. 오버로딩한 메서드는 원래의 메서드를 가리지 않기 때문에 이 메서드들은 사이좋게 공존한다. +다음은 오버로딩의 예를 나타낸 것이다. Money 클래스에 구현된 두개의 plus 메서드는 이름은 같지만 하나는 Money타입의 파라미터를, 다른 하나는 log 타입의 파라미터를 받도록 정의돼 있다. + +> 이경우 두 메서드는 공존하며 외부에서는 두개의 메서드 모두 호출할 수 있다. +따라서 이 경우에는 오버라이딩이라고 부르지 않고 오버로딩이라고 부른다. + +```java +Public class Money { + public Money plus ( Money amount ) { + return new Money(this.amount.add(amount.amount)); + } + + public Money plus ( long amount ) { + return new Money(this.amount.add(BigDecimal.valuOf(amount))); + } +} + +``` + + + + + +### 04 상속과 다형성 + +#### 컴파일 시간 의존성과 실행 시간 의존성 + +- > *코드의 의존성과 실행 시점의 의존성이 다르면 다를수록 코드를 이해하기 어려워진다는 것이다. 코드를 이해하기 위해서는 코드뿐만 아니라 객체를 생성하고 연결하는 부분을 찾아야 하기 때문이다. 반면 코드의 의존성과 실행 시점의 의존성이 다르면 다를수록 코드는 더 유연해지고 확장 가능해진다. +이와 같은 의존성의 양면성은 설계가 트레이드오프의 산물이라는 사실을 잘 보여준다.* + +- > *설계가 유연해질수록 코드를 이해하고 디버깅하기는 점점 더 어려워진다는 사실을 기억하라. 반면 유연성을 억제하면 코드를 이해하고 디버깅하기는 쉬워지지만 재사용성과 확장 가능성은 낮아진다는 사실도 기억하라. 여러분이 훌륭한 객체지향 설계자로성장하기 위해서는 항상 유연성과 가독성 사이에서 고민해야 한다. 무조건 유연한 설계도, 무조건 읽기 쉬운 코드도 정답이 아니다. 이것이 객체지향 설계가 어려우면서도 매력적인 이유다.* + +- 이와 같은 딜레마를 알기 위해서는 설계를 많이 해봐야한다는 멘토님의 말씀 + + +#### 차이에 의한 프로그래밍 + +- 부모 클래스와 다른 부분만을 추가해서 새로운 클래스를 쉽고 빠르게 만드는 방법입니다. + + +#### 상속과 인터페이스 + +- 자식 클래스가 부모클래스를 대신하는 것을 업캐스팅이라고 부릅니다.(upcasting) + +SOLID (객체 지향 설계)원칙중 L에 해당하는 -리스코프 치환 원칙 (ft. 멘토님) + +리스코프가 사람이름이었던것도 멘토님이 얘기해주셔서 알았고 궁금해서 검색했더니 + +![화면 캡처 2021-02-12 123019](https://user-images.githubusercontent.com/2981954/107727270-3fb9da80-6d2e-11eb-887a-6263287f3d8c.jpg) + +![화면 캡처 2021-02-12 123104](https://user-images.githubusercontent.com/2981954/107727272-40527100-6d2e-11eb-93fa-73dbca99f92d.jpg) + +이 분이십니다. + +#### 다형성 + +- 다시 한번 강조하지만 메시지와 메서드는 다른 개념입니다. + +- 실제로 어떤 메서드가 실행될 것인지는 메세지를 수신하는 객체의 클래스가 무엇이냐에 따라 달라지는데 이를 **다형성**이라고 부릅니다. + +- 다형성은 컴파일 시간 의존성과 실행 시간 의존성을 다르게 만들 수 있는 객체지향의 특성을 이용해 서로 다른 메서드를 실행할 수 있게 합니다. + +- 다형성을 구현하는 방법으로는 지연 바인딩(lazy binding)(또는 동적 바인딩(dynamic binding))이 있고 이는 메시지와 메서드를 실행 시점에 바인딩하는 것입니다. + +- 객체지향이 컴파일 시점의 의존성과 실행 시점의 의존성을 분리하고, 하나의 메시지를 선택적으로 서로 다른 메서드에 연결할 수 있는 이유가 바로 지연 바인딩이라는 메커니즘을 사용하기 때문입니다. + +**구현 상속과 인터페이스 상속** + +- >상속을 구현 상속(implememtation inheritance)과 인터페이스 상속(interface inheritance)으로 분류할 수 있다. 흔히 구현 상속을 서브클래싱(subclassing)이라고 부르고 인터페이스 상속을 서브타이핑(subtyping)이라고 부른다. 순수하게 코드를 재사용하기 위한 목적으로 상속을 사용하는 것을 구현 상속이라고 부른다. + +- >다형적인 협력을 위해 부모 클래스와 자식 클래스가 인터페이스를 공유할 수 있도록 상속을 이용하는 것을 인터페이스 상속이라고 부른다. + +- >상속은 구현 상속이 아니라 인터페이스 상속을 위해 사용해야 한다. 대부분의 사람들은 코드 재사용을 상속의 주된 목적이라고 생각하지만 이것은 오해다. 인터페이스를 재사용할 목적이 아니라 구현을 재사용할 목적으로 상속을 사용하면 변경에 취약한 코드를 낳게 될 확률이 높다. + +#### 인터페이스와 다형성 + +- 구현은 공유할 필요가 없고 순수하게 인터페이스만 공유하고 싶을때 있습니다. +- 이를 위해 C#과 자바에서는 인터페이스라는 프로그래밍 요소를 제공합니다. + + + +### 05 추상화와 유연성 + +#### 추상화의 힘 + +1. 추상화를 사용하면 세부적인 내용을 무시한 채 상위 정책을 쉽고 간단하게 표현할 수 있습니다. + + - 추상화를 이용해 상위 정책을 기술한다는 것은 기본적인 애플리케이션의 협력 흐름을 기술한다는 것을 의미합니다. + + - 재사용 가능한 설계의 기본을 이루를 디자인 패턴(design pattern)이나 프레임워크(framework) 모두 추상화를 이용해 상위 정책을 정의하는 객체지향의 메커니즘을 활용하고 있기 때문입니다. + +2. 설계를 유연하게 만들 수 있습니다. + + + +#### 추상 클래스와 인터페이스 트레이드오프 + +- 구현과 관련된 모든 것들이 트레이드오프의 대상이 될 수 있습니다. + +- 여러분이 작성하는 모든 코드에는 합당한 이유가 있어야 합니다. + +- 비록 아주 사소한 결정이더라도 트레이드오프를 통해 얻어진 결론과 그렇지 않은 결론 사이의 차이는 큽니다. 고민하고 트레이드오프해야 합니다. + + + +#### 상속 + +- 상속은 객체지향에서 코드를 재사용하기 위해 널리 사용하는 기법입니다. + +- 하지만 두가지 관점에서 설계에 안좋은 영향을 미칩니다. 상속이 캡슐을 위반화한다는 것이고, 다른 하나는 설계를 유연하지 못하게 만든다는 것입니다. + +#### 합성 + +- 인터페이스에 정의된 메시지를 통해서만 코드를 재사용하는 방법을 **합성**이라고 부릅니다. + +- 합성은 상속이 가지는 두가지 문제점을 모두 해결합니다. + +- 인터페이스에 정의된 메시지를 통해서만 재사용이 가능하기 때문에 구현을 효과적으로 캡슐화할 수 있습니다. + +- 또한 의존하는 인스턴스를 교체하는 것이 비교적 쉽기 때문에 설계를 유연하게 만듭니다. + +- 따라서 코드 재사용을 위해서는 상속보다는 합성을 선호하는 것이 더 좋은 방법입니다. + + +## 느낀점 + +- 객체지향 프로그래밍을 직접 해보고 싶은 생각이 들었습니다. + +- 직접 설계와 구현을 하면 지금보다는 좀 더 와닿을거 같습니다. 😂 + + + + + + + + + + From 89092048ed33f5a1933aa3c9870c3611980966de Mon Sep 17 00:00:00 2001 From: jongfeel Date: Mon, 8 Feb 2021 03:16:52 +0900 Subject: [PATCH 2/3] Add object book discussions --- Booktalk/Object/FeelsDiscussion1.md | 88 +++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+) create mode 100644 Booktalk/Object/FeelsDiscussion1.md diff --git a/Booktalk/Object/FeelsDiscussion1.md b/Booktalk/Object/FeelsDiscussion1.md new file mode 100644 index 0000000..d33509c --- /dev/null +++ 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)라는 책에서도 동일하고 트레이드 오프에 대해 언급을 하고 있고, 상속과 인터페이스의 간극에 대해 유연하면서도 상황에 맞게 사용할 줄 아는 혜안을 가지는게 객체지향 설계의 묘미라고도 하였다. +- 복잡한 비지니스 프로세스를 여러번 경험하고 나면 이 트레이드 오프가 의미가는 바를 더 잘 알게 될 것이라고 생각하며, 책에서 언급한 내용만으로는 이해할 수 없다고 본다. \ No newline at end of file From 4f3978255fdfff1ba0d860d4ea055f164fa3d862 Mon Sep 17 00:00:00 2001 From: yucho Date: Fri, 5 Mar 2021 10:27:55 +0900 Subject: [PATCH 3/3] =?UTF-8?q?Objects=2001,03-04=20=EA=B0=9D=EC=B2=B4?= =?UTF-8?q?=EC=A7=80=ED=96=A5=20=ED=94=84=EB=A1=9C=EA=B7=B8=EB=9E=98?= =?UTF-8?q?=EB=B0=8D=20Discussions?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Booktalk/Object/YoonusDiscussion2.md | 136 +++++++++++++++++++++++++++ 1 file changed, 136 insertions(+) create mode 100644 Booktalk/Object/YoonusDiscussion2.md diff --git a/Booktalk/Object/YoonusDiscussion2.md b/Booktalk/Object/YoonusDiscussion2.md new file mode 100644 index 0000000..f6f4c0a --- /dev/null +++ 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 - 데이터 중심 설계는 객체를 고립시킨채 오퍼레이션을 정의하도록 만든다 + +내코드는 당연하게도 고립되어 있었겠다 싶어져서 갑자기 코드에게 미안(?)해진다. 앞으로는 객체지향적인 생각을 하도록 의도적으로라도 노력을 해야겠다는 생각이 든다. + + + + + + +