닭발개발

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

22일차. 오브젝트: 코드로 이해하는 객체지향 설계[4주차_목요일] 277-290pg #요약 **Chapter 08. 의존성 관리하기** 01. 의존성 이해하기 02. 유연한 설계 8) 컨텍스트 확장하기 - 결합도를 낮춤으로써 얻게 되는 컨텍스트의 확장이라는 개념이 유연하고 재사용 가능한 설계를 만든다. 9) 조합 가능한 행동 - 어떤 객체와 협력하느냐에 따라 객체의 행동이 달라지는 것은 유연하고 재사용 가능한 설계가 가진 특징 - 유연&재사용 가능한 설계는 객체가 어떻게 하는지를 장황하게 나열하지 않고도 객체들의 조합을 통해 무엇을 하는지를 표현하는 클래스로 구성됨. - 선언적으로 객체의 행동을 정의할 수 있음 **Chapter 09. 유연한 설계** - 8장에서 유연하고 재사용가능한 설계를 만드려고 ..

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

19일차. 오브젝트: 코드로 이해하는 객체지향 설계[4주차_월요일] 235-249pg #요약 **Chapter 07. 객체 분해** 01. 프로시저 추상화와 데이터 추상화 02. 프로시저 추상화와 기능 분해 03. 모듈 1) 정보 은닉과 모듈 - 기능을 기반으로 시스템을 분해하는 것이 아니라 변경의 방향에 맞춰 시스템 변경 - 정보 은닉(information hiding) : 시스템을 모듈 단위로 분해하기 위한 기본 원리. 시스템에서 자주 변경되는 부분을 상대적으로 덜 변경되는 안정적인 인터페이스 뒤로 감춰야 한다. - 기능 분해가 하나의 기능을 구현하기 위해 필요한 기능들을 순차적으로 찾아가는 탐색의 과정이라면 모듈 분해는 감춰야 하는 비밀을 선택하고 비밀 주변에 안정적인 보호막을 설치하는 보존의 과정..

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) 명령-쿼리 분리와 참조 투명성 - 함수형 프로그래밍 : 부수효과가 존재하지 않는 수학적인 함수에 기반. 참조 투명..

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

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