닭발개발

25일차. 오브젝트: 코드로 이해하는 객체지향 설계[5주차_월요일] 322-335pg #요약 **Chapter 10. 상속과 코드 재사용** - 객체지향에서는 코드 재사용을 위해 '새로운'코드를 추가하는데 코드는 보통 클래스 안에서 작성되니까 새로운 클래스를 추가한다. - 클래스를 재사용하기 위해 새로운 클래스를 추가하는 가장 대표적 기법 : 상속 - 클래스의 인스턴스 안에 기존 클래스의 인스턴스를 포함시키는 방법 : 합성 01. 상속과 중복코드 - 중복코드를 제거해야 할 이유 1) DRY 원칙 2) 중복과 변겅 3) 상속을 이용해서 중복 코드 제거하기 4) 강하게 결합된 Phone과 NightlyDiscountPhone - 기반 클래스 문제 : 상속 관계로 연결된 자식 클래스가 부모 클래스의 변경에 취..

23일차. 오브젝트: 코드로 이해하는 객체지향 설계[4주차_금요일] 291-304pg #요약 **Chapter 09. 유연한 설계** - 8장에서 유연하고 재사용가능한 설계를 만드려고 적용할 수 있는 다양한 의존성 관리 기법들을 소개했다면 9장에서는 이 기법들을 원칙이라는 관점에서 정리 01. 개방-폐쇄 원칙(Open-Closed Principle, OCP) 02. 생성 사용 분리 - 결합도가 높을수록 개방폐쇄 원칙을 따르는 구조를 설계하기 어려워진다. - 동일 클래스에서 객체 생성과 사용의 두 가지 이질적 목적을 가진 코드가 공존하는 것이 문제 -> 객체와 관련된 두 책임을 서로 다른 객체로 분리해야 함. - 객체에 대한 생성과 사용을 분리. - 사용으로부터 생성을 분리하는 방법은 객체를 생성할 책임을..

21일차. 오브젝트: 코드로 이해하는 객체지향 설계[4주차_수요일] 264-276pg #요약 **Chapter 08. 의존성 관리하기** 01. 의존성 이해하기 1) 변경과 의존성 2) 의존성 전이 3) 런타임 의존성과 컴파일타임 의존성 4) 컨텍스트 독립성 5) 의존성 해결하기 클래스의 메서드를 호출하는 대부분의 경우에 매번 동일한 객체를 인자로 전달하고 있다면 생성자를 이용하거나 setter 메서드를 이용해 의존성을 지속적으로 유지하는 방식으로 변경하는게 좋다. 02. 유연한 설계 의존성과 결합도의 관계 살펴보기 1) 의존성과 결합도 - 객체의 협력을 위해서는 서로의 존재와 수행 가능한 책임을 알아야 한다. - 의존성이 과하면 문제가 된다. - 바람직한 의존성? 재사용성이 있는 의존성, 컨텍스트에 독..

18일차. 오브젝트: 코드로 이해하는 객체지향 설계[3주차_토요일] 225-234pg #요약 **Chapter 07. 객체 분해** 01. 프로시저 추상화와 데이터 추상화 02. 프로시저 추상화와 기능 분해 1) 메인 함수로서의 시스템 2) 급여 관리 시스템 3) 급여관리 시스템 구현 - 하향식 기능 분해는 시스템을 최상위의 가장 추상적인 메인 함수로 정의하고, 메인 함수를 구현 가능한 수준까지 세부적인 단계로 분해하는 방법 - 하향식 기능 분해 방식으로 설계한 시스템은 메인 함수를 루트로 하는 '트리(tree)'로 표현할 수 있다. 4) 하향식 기능 분해의 문제점 - 시스템은 하나의 메인 함수로 구성되어 있지 않다. - 기능 추가나 요구사항 변경으로 인해 메인 함수를 빈번하게 수정해야 한다. - 비즈니..

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) : 메시지 전송자가 수신자의 내부 구조에 대해 물어보고 반환받은 요소에..

14일차. 오브젝트: 코드로 이해하는 객체지향 설계[3주차_화요일] 172-185pg #요약 **Chapter 05. 책임 할당하기** - 책임에 초점을 맞춰서 설계할 때는 어떤 객체에 어떤 책임을 할당할지 결정하기가 쉽지 않다. - 책임 할당 과정은 일종의 트레이드오프 활동 - GRASP 패턴은 책임 할당의 어려움을 해결하기 위한 답을 제시해줄 것. 01. 책임 주도 설계를 향해 02. 책임 할당을 위한 GRASP 패턴 03. 구현을 통한 검증 04. 책임 주도 설계의 대안 1) 메서드 응집도 2) 객체를 자율적으로 만들자 - 어떤 메소드를 어떤 클래스로 이동? 메소드가 사용하는 데이터를 저장하고 있는 클래스로 메서드를 이동시킨다. - 데이터를 사용하는 메서드를 데이터를 가진 클래스로 이동시키고 나면 ..

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(정보 전문가) 패..