닭발개발

11일차. 오브젝트: 코드로 이해하는 객체지향 설계[2주차_금요일] 131-141pg #요약 **Chapter 04. 실제 품질과 트레이드오프** 데이터 중심의 접근법을 취할 경우 직면하게 되는 다양한 문제점들 06. 데이터 중심 설계의 문제점 - 데이터 중심의 설계는 너무 빨리 데이터에 관해 결정하도록 한다. - 협력을 고려하지 않고 객체를 고립시킨 채 오퍼레이션을 결정한다. 1) 데이터 중심 설계는 객체의 행동보다는 상태에 초점을 맞춘다. - 데이터 중심 설계에 익숙하면 절차적 프로그래밍을 하게 된다. - 데이터 중심 관점에서 객체는 그저 단순한 데이터의 집합체일 뿐이다. - 데이터에 초점을 맞추면 만족스러운 캡슐화를 얻기 어렵다. 2) 데이터 중심 설계는 객체를 고립시킨 채 오퍼레이션을 정의하도록 ..

10일차. 오브젝트: 코드로 이해하는 객체지향 설계[2주차_목요일] 119-130pg #요약 **Chapter 04. 실제 품질과 트레이드오프** 04. 자율적인 객체를 향해 2) 스스로 자신의 데이터를 책임지는 객체 - 상태와 행동을 객체라는 하나의 단위로 묶는 이유는 객체 스스로 자신의 상태를 처리할 수 있게 하기 위해서다. - 이 객체가 어떤 데이터를 포함해야 하는지, 데이터에 대해 수행해야 하는 오퍼레이션은 무엇인지 - 데이터를 처리하는 데 필요한 메서드를 데이터를 가지고 있는 객체 스스로 구현하고 있다. 05. 하지만 여전히 부족하다. 1) 캡슐화 위반 - 내부의 구현의 변경이 외부로 퍼져나가는 파급효과(ripple effect)는 캡슐화가 부족하다는 명백한 증거다. - 캡슐화의 진정한 의미 :..

9일차. 오브젝트: 코드로 이해하는 객체지향 설계[2주차_수요일] 108-118pg #요약 **Chapter 04. 실제 품질과 트레이드오프** 2) 영화를 예매하자 02. 설계 트레이드오프 1) 캡슐화 - 한 곳에서 일어난 변경이 전체 시스템에 영향을 끼치지 않도록 파급효과를 적절하게 조절할 수 있는 장치 제공 - 변경될 가능성이 높은 부분은 구현, 상대적으로 안정적인 부분은 인터페이스 2) 응집도와 결합도 - 응집도 : 모듈에 포함된 내부 요소들이 연관돼 있는 정도를 나타냄 - 모듈 내의 요소들이 하나의 목적을 위해 긴밀하게 협력한다면 그 모듈은 높은 응집도를 가진다. - 변경의 관점에서 응집도란 변경이 발생할 때 모듈 내부에서 발생하는 변경의 정도로 측정할 수 있다. - 응집도가 높을수록 변경의 대..

8일차. 오브젝트: 코드로 이해하는 객체지향 설계[2주차_화요일] 92-107pg #요약 **Chapter 03. 역할, 책임, 협력** - 객체지향 패러다임의 관점에서 핵심은 역할, 책임, 협력이다. 03. 역할 3) 객체 대 역할 - 역할 모델링 : 역할을 설계의 중심 개념으로 봄. - 역할의 가장 큰 장점은 설계의 구성 요소를 추상화할 수 있다는 것 4) 역할과 추상화 - 역할은 공통의 책임을 바탕으로 객체의 종류를 숨기기 때문에 이런 관점에서 역할을 객체의 추상화로 볼 수 있다. - 협력의 관점에서는 세부적인 사항을 무시하고 추상화에 집중하는 것이 유용하다. 5) 배우와 배역 - 동일한 배역을 여러 명의 배우들이 연기할 수 있음 - 협력 안에서 역할을 수행하는 객체 - 객체는 협력이 끝나고 협력에..

7일차. 오브젝트: 코드로 이해하는 객체지향 설계[2주차_월요일] 78-91pg #요약 **Chapter 03. 역할, 책임, 협력** - 객체지향 패러다임의 관점에서 핵심은 역할, 책임, 협력이다. 02. 책임 1) 책임이란 무엇인가. - 책임 : 협력에 참여하기 위해 객체가 수행하는 행동 - 객체의 책임은 객체가 '무엇을 알고 있는가'와 '무엇을 할 수 있는가'로 구성된다. - CRC 카드: Candidate(후보), Responsibility(책임), Collaborator(협력자). 하나의 CRC 카드는 협력에 참여하는 하나의 후보를 표현한다. 2) 책임할당 - 책임을 수행하는 데 필요한 정보를 가장 잘 알고 있는 전문가에게 그 책임을 할당하는 것 => Information Expert(정보 전문..

6일차. 오브젝트: 코드로 이해하는 객체지향 설계[1주차_토요일] 65~77pg #요약 **Chapter 02. 객체지향 프로그래밍** (feat. 가벼운 마음가짐) 05. 추상화와 유연성 1) 추상화의 힘. - 추상화 사용의 장점1 : 추상화의 계층만 따로 떼어 놓고 살펴보면 요구사항의 정책을 높은 수준에서 서술할 수 있다는 것. - 추상화 사용의 장점2 : 추상화를 이용하면 설계가 좀 더 유연해진다는 것. - 디자인패턴, 프레임워크 모두 추상화를 이용해 상위 정책을 정의하는 객체지향의 메커니즘을 활용하고 있다. 2) 유연한 설계 - 항상 예외 케이스를 최소화하고 일관성을 유지할 수 있는 방법을 선택하라 3) 추상 클래스와 인터페이스 트레이드오프 - 구현과 관련된 모든 것들이 트레이드오프의 대상이 될 ..

5일차. 오브젝트: 코드로 이해하는 객체지향 설계[1주차_금요일] 51~64pg #요약 **Chapter 02. 객체지향 프로그래밍** (feat. 가벼운 마음가짐) 03. 할인요금 구하기 - TEMPLATE METHOD PATTERN : 부모 클래스에 기본적인 알고리즘의 흐름을 구현하고 중간에 필요한 처리를 자식 클래스에게 위임하는 디자인 패턴. - 오버라이딩(overriding) : 부모 클래스에 정의된 같은 이름, 같은 파라미터 목록을 가진 메서드를 자식 클래스에서 재정의하는 경우. 자식 클래스의 메서드는 오버라이딩한 부모 클래스의 메서드를 가리키기 때문에 외부에서는 부모 클래스의 메서드가 보이지 않는다. - 오버로딩(overloading) : 메서드의 이름은 같지만 제공되는 파라미터의 목록이 다르..

4일차. 오브젝트: 코드로 이해하는 객체지향 설계[1주차_목요일] 34~50pg #요약 **Chapter 01. 객체, 설계** - 휼륭한 객체지향 설계란 소프트웨어를 구성하는 모든 객체들이 자율적으로 행동하는 설계를 가리킨다. 04. 객체지향 설계 - 설계는 코드를 작성하는 매 순간 코드를 어떻게 배치할 것인지를 결정하는 과정에서 나온다. - 오늘 완성해야 하는 기능을 구현하는 코드를 짜야 하는 동시에 내일 쉽게 변경할 수 있는 코드를 짜야 한다. - 변경을 수용할 수 있는 설계가 중요한 이유1. 요구사항이 항상 변경됨. 2. 코드를 변경할 때 버그가 추가될 가능성이 높기 때문. - 객체 지향의 세계에서 애플리케이션은 객체들로 구성되며 애플리케이션의 기능은 객체들 간의 상호작용을 통해 구현된다. - 훌..

3일차. 오브젝트: 코드로 이해하는 객체지향 설계[1주차_수요일] 17~33pg #요약 **Chapter 01. 객체, 설계** - 결합도(coupling)가 높음 : 객체 사이의 의존성이 과한 경우 - 변경과 의사소통의 문제는 서로 엮어 있음 : 의도를 정확하게 의사소통하지 못하기 때문에 코드가 이해하기 어려워진 것. => 해결 : 극장이 관객과 매표소에 관해 너무 세세한 부분까지 알지 못하도록 정보를 차단하면 된다. 즉, 관객과 매표소를 자율적인 존재로 만들면 된다. [ 자율성을 높이자 ] - TicketSeller에서 getTicketOffice 메소드가 제거 됨. -> 결과적으로 ticketOffice에 대한 접근은 오직 TicketSeller안에만 존재하게 된다. -> 캡슐화(encapsulat..

2일차. 오브젝트: 코드로 이해하는 객체지향 설계[1주차_화요일] 2~16pg #요약[ 들어가며: 프로그래밍 패러다임 ] 우리는 패러다임의 홍수 속에 살고있음. - 패러다임 전환(Paradigm Shift) : 우주를 바라보는 관점이 천동설 -> 지동설로 변화 - 이 책에서의 패러다임 전환 : 절차형 패러다임 -> 객체지향 패러다임으로 변화 - 우리가 어떤 프로그래밍 패러다임을 사용하느냐에 따라 우리가 해결할 문제를 바라보는 방식과 프로그램을 작성하는 방법이 달라진다. - 프로그래밍 패러다임은 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 함으로써 불필요한 부분에 대한 의견 충돌을 방지한다. - 이 책은 객체지향 패러다임에 관한 책 - 이 책의 목적 : 객체지향 패러다임이 제시하는 프..