닭발개발

17일차. 오브젝트: 코드로 이해하는 객체지향 설계[3주차_금요일] 214-224pg #요약 **Chapter 06. 메시지와 인터페이스** - 클래스라는 구현 도구에 지나치게 집착하면 경직되고 유연하지 못한 설계에 이르게 된다. - 협력 안에서는 객체가 수행하는 책임에 초점을 맞춰야 하는데, 책임이 객체가 수신할 수 있는 메시지의 기반이 된다. - 애플리케이션은 클래스로 구성되지만 메세지를 통해 정의된다. 01. 협력과 메세지 02. 인터페이스와 설계품질 03. 원칙의 함정 04. 명령-쿼리 분리 법칙(Command-Query Separation) 1) 반복일정의 명령과 쿼리 분리하기 2) 명령-쿼리 분리와 참조 투명성 - 함수형 프로그래밍 : 부수효과가 존재하지 않는 수학적인 함수에 기반. 참조 투명..

16일차. 오브젝트: 코드로 이해하는 객체지향 설계[3주차_목요일] 199-213pg #요약 **Chapter 06. 메시지와 인터페이스** - 클래스라는 구현 도구에 지나치게 집착하면 경직되고 유연하지 못한 설계에 이르게 된다. - 협력 안에서는 객체가 수행하는 책임에 초점을 맞춰야 하는데, 책임이 객체가 수신할 수 있는 메시지의 기반이 된다. - 애플리케이션은 클래스로 구성되지만 메세지를 통해 정의된다. 01. 협력과 메세지 02. 인터페이스와 설계품질 03. 원칙의 함정 - 디미터 법칙이 절대적인건 아니다. 소프트웨어 설계에 법칙이란 존재하지 않는다. - 잊지마! 설계는 트레이드 오프의 산물이라는 것을. - 원칙이 현재 상황에 부적합 하다고 판단되면 과감하게 원칙을 무시하라 - 원칙을 아는 것보다 ..

15일차. 오브젝트: 코드로 이해하는 객체지향 설계[3주차_수요일] 186-198pg #요약 **Chapter 06. 메시지와 인터페이스** - 클래스라는 구현 도구에 지나치게 집착하면 경직되고 유연하지 못한 설계에 이르게 된다. - 협력 안에서는 객체가 수행하는 책임에 초점을 맞춰야 하는데, 책임이 객체가 수신할 수 있는 메시지의 기반이 된다. - 애플리케이션은 클래스로 구성되지만 메세지를 통해 정의된다. 01. 협력과 메세지 1) 클라이언트-서버 모델 2) 메시지와 메시지 전송 3) 메시지와 메서드 4) 퍼블릭 인터페이스와 오퍼레이션 5) 시그니쳐 02. 인터페이스와 설계품질 1) 디미터 법칙 - 기차 충돌(train wreck) : 메시지 전송자가 수신자의 내부 구조에 대해 물어보고 반환받은 요소에..

13일차. 오브젝트: 코드로 이해하는 객체지향 설계[3주차_월요일] 156-171pg #요약 **Chapter 05. 책임 할당하기** - 책임에 초점을 맞춰서 설계할 때는 어떤 객체에 어떤 책임을 할당할지 결정하기가 쉽지 않다. - 책임 할당 과정은 일종의 트레이드오프 활동 - GRASP 패턴은 책임 할당의 어려움을 해결하기 위한 답을 제시해줄 것. 01. 책임 주도 설계를 향해 1) 데이터보다 행동을 먼저 결정하라. 2) 협력이라는 문맥 안에서 책임을 결정하라 3) 책임 주도 설계 02. 책임 할당을 위한 GRASP 패턴 1) 도메인 개념에서 출발하기 2) 정보 전문가에게 책임을 할당하라. 3) 높은 응집도와 낮은 결합 4) 창조자에게 객체 생성 책임을 할당하라. 03. 구현을 통한 검증 - 메시지가..

12일차. 오브젝트: 코드로 이해하는 객체지향 설계[2주차_토요일] 142-155pg #요약 **Chapter 05. 책임 할당하기** - 책임에 초점을 맞춰서 설계할 때는 어떤 객체에 어떤 책임을 할당할지 결정하기가 쉽지 않다. - 책임 할당 과정은 일종의 트레이드오프 활동 - GRASP 패턴은 책임 할당의 어려움을 해결하기 위한 답을 제시해줄 것. 01. 책임 주도 설계를 향해 1) 데이터보다 행동을 먼저 결정하라. 2) 협력이라는 문맥 안에서 책임을 결정하라 3) 책임 주도 설계 02. 책임 할당을 위한 GRASP 패턴 1) 도메인 개념에서 출발하기 2) 정보 전문가에게 책임을 할당하라. - 수행할 정보를 알고 있는 객체에게 책임을 할당하는 것 : Information Expert(정보 전문가) 패..

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) : 메서드의 이름은 같지만 제공되는 파라미터의 목록이 다르..