닭발개발

48일차. 오브젝트: 코드로 이해하는 객체지향 설계[8주차_토요일] 마지막날 604-615pg #요약 **APPENDIX C. 동적인 협력, 정적인 코드** 01. 동적 모델과 정적 모델 1) 행동이 코드를 결정한다. - 동적 모델이 정적 모델을 결정해야 한다. 2) 변경을 고려하라 -객체지향 설계 관련 다른 도서에서는 도메인 모델을 먼저 만들고 도메인 모델을 기반으로 설계와 구현을 진행하라고 했는데, 도메인 안의 개념과 관계를 담고 있는 도메인 모델은 정적 모델인데? 02. 도메인 모델과 구현 1) 도메인 모델에 관하여 - 도메인 : 사용자가 프로그램을 사용하는 대상영역 - 모델 : 지식을 선택적으로 다순화하고 의식적으로 구조화한 형태 - 도메인 모델 : 사용자가 프로그램을 사용하는 대상 영역에 대한 ..

47일차. 오브젝트: 코드로 이해하는 객체지향 설계[8주차_금요일] 588-603pg #요약 **APPENDIX B. 타입계층의 구현** 1) 클래스를 이용한 타입 계층 구현 2) 인터페이스를 이용한 타입 계층 구현 3) 추상 클래스를 이용한 타입 계층 구현 4) 추상 클래스와 인터페이스 결합하기 5) 덕 타이핑 사용하기 - 덕 타이핑 : 주로 동적 타입 언어에서 사용하는 방법으로, 덕 테스트(duck test)를 프로그래밍 언어에 적용한 것. - 덕 테스트 : "어떤 새가 오리처럼 걷고, 오리처럼 헤엄치며, 오리처럼 꽥꽥 소리를 낸다면 나는 이 새를 오리라고 부를 것이다", 어떤 대상의 '행동'이 오리와 같다면 그것을 오리라는 타입으로 취급해도 무방하다는 것. - 즉, 객체가 어떤 인터페이스에 정의된 ..

46일차. 오브젝트: 코드로 이해하는 객체지향 설계[8주차_목요일] 574-587pg #요약 **APPENDIX B. 타입계층의 구현** - 타입 계층을 구현할 수 있는 다양한 방법들 1) 클래스를 이용한 타입 계층 구현 - 객체지향 언어에서 클래스를 사용자 정의 타입이라고 부르는 이유는 타입은 객체의 퍼블릭 인터페이스를 가리키기 때문에 결과적으로 클래스는 객체의 타입과 구현을 동시에 정의하는 것과 같기 때문이다. - 상속을 이용하면 자식 클래스가 부모 클래스의 구현뿐만 아니라 퍼블릭 인터페이스도 물려받을 수 있기 때문에 타입 계층을 쉽게 구현할 수 있는데, 구체 클래스를 상속받으면 안되고 가급적 추상 클래스를 상속받거나 인터페이스를 구현해야 한다. 2) 인터페이스를 이용한 타입 계층 구현 - 상속으로 ..

45일차. 오브젝트: 코드로 이해하는 객체지향 설계[8주차_수요일] 558-573pg #요약 **APPENDIX. 계약에 의한 설계** 01. 협력과 계약 02. 계약에 의한 설계 03. 계약에 의한 설계와 서브타이핑 1) 계약 규칙 2) 가변성 규칙 - 부모 클래스보다 못한 자식 클래스는 서브타입이 아니다. - 서브타이핑과 공변성, 반공변성 사이의 관계 - S가 T의 서브타입일 때 공변성, 반공변성, 무공변성 . 공변성 : S와 T사이 서브타입 관계가 그대로 유지됨 . 반공변성 : S와 T사이 서브타입 관계가 역전됨 . 무공변성 : S와 T사이에는 아무런 관계도 없음 - 공변성과 반공변성의 영역으로 들어서려면 타입의 관계가 아니라 메서드의 리턴 타입과 파라미터 타입에 초점을 맞춰야 한다. - 리턴 타입..

44일차. 오브젝트: 코드로 이해하는 객체지향 설계[8주차_화요일] 547-557pg #요약 **APPENDIX. 계약에 의한 설계** 01. 협력과 계약 02. 계약에 의한 설계 03. 계약에 의한 설계와 서브타이핑 - 서브타입이 리스코프 치환 원칙을 만족시키기 위해서는 클라이언트와 슈퍼타입 간에 체결된 계약을 준수해야 한다. - 리스코프 치환원칙의 규칙 a. 계약 규칙 : 슈퍼타입과 서브타입 사이의 사전조건, 사후조건, 불변식에대해 서술할 수 있는 제약에 관한 규칙 b. 가변성 규칙 : 파라미터와 리턴 타입의 변형과 관련된 규칙 1) 계약 규칙 - 사전조건 완화는 리스코프 치환 원칙을 위반하지 않는다. - 사후조건 완화는 리스코프 치환 원칙 위반이다.

43일차. 오브젝트: 코드로 이해하는 객체지향 설계[8주차_월요일] 538-546pg #요약 **APPENDIX. 계약에 의한 설계** 01. 협력과 계약 1) 부수효과를 명시적으로 2) 계약 - 계약은 협력을 명확하게 정의하고 커뮤니케이션할 수 있는 범용적인 아이디어. 02. 계약에 의한 설계 - 버트란드 마이어가 제시한 계약의 개념 . 협력에 참여하는 각 객체는 계약으로부터 이익을 기대하고 이익을 얻기 위해 의무를 이행한다. . 협력에 참여하는 각 객체의 이익과 의무는 객체의 인터페이스 상에 문서화된다. - 계약에 의한 설계를 이용하면 오퍼레이션의 시그니처를 구성하는 다양한 요소들을 이용해 협력에 참여하는 객체들이 지켜야 하는 제약 조건을 명시할 수 있다. - 의도를 드러내는 인터페이스를 만들면 오퍼..

42일차. 오브젝트: 코드로 이해하는 객체지향 설계[7주차_토요일] 528-537pg #요약 **Chapter 15. 디자인 패턴과 프레임 워크** 01. 디자인 패턴과 설계 재사용 02. 프레임워크와 코드 재사용 1) 코드 재사용 vs 설계 재사용 2) 상위 정책과 하위 정책으로 패키지 분리하기 3) 제어 역전 원리 - 상위 정책을 재사용하는 것은 도메인에 있는 핵심 개념들 사이의 협력관계를 재사용한다는 의미 - 객체지향 설계의 재사용성은 개별 클래스가 아니라 객체들 사이의 공통적인 협력 흐름으로부터 나온다. - 의존성 역전 원리는 전통적 설계방법과 객체지향을 구분하는 핵심원리 - 시스템이 진화하는 방향에는 항상 의존성 역전 원리를 따르는 설계가 존재해야 한다. - 의존성 역전 원리는 프레임워크의 가장..

41일차. 오브젝트: 코드로 이해하는 객체지향 설계[7주차_금요일] 519-527pg #요약 **Chapter 15. 디자인 패턴과 프레임 워크** 01. 디자인 패턴과 설계 재사용 1) 소프트웨어 패턴 2) 패턴 분류 3) 패턴과 책임-주도 설계 4) 캡슐화와 디자인패턴 - 대부분의 디자인 패턴은 협력을 일관성 있고 유연하게 만드는게 목적임 - STRATEGY 패턴은 알고리즘의 변경을 캡슐화하고 그것을 위해서 객체 합성을 이용한다. - 알고리즘을 캡슐화하기 위해 합성 관계가 아닌 상속 관계를 사용하는 것은 Template method 패턴 - 추상 클래스나 인터페이스를 사용해 변경을 캡슐화하는 합성과 달리 - 상속을 사용할 때는 추상 메서드를 이용해서 변경을 캡슐화 해야 함 - 템플릿 메소드 패턴은 합..

40일차. 오브젝트: 코드로 이해하는 객체지향 설계[7주차_목요일] 505-518pg #요약 **Chapter 14. 일관성 있는 협력** 01. 핸드폰 과금 시스템 변경하기 02. 설계에 일관성 부여하기. 03. 일관성 있는 기본 정책 구현하기 1) 변경 분리하기 2) 변경 캡슐화하기 3) 협력 패턴 설계하기 4) 추상화 수준에서 협력 패턴 구현하기 5) 구체적인 협력 구현하기 - 일관성 있는 협력은 개발자에게 확장 포인트를 강제하기 때문에 정해진 구조를 우회하기 어렵게 만든다. - 유사한 기능에 대해 유사한 협력 패턴을 적용하는 것은 객체지향 시스템에서 개념적 무결성을 유지할 수 있는 가장 효과적 방법이다. - 시스템이 일관성 있는 몇 개의 협력 패턴으로 구성된다면 시스템을 이해, 수정, 확장하는 데..

39일차. 오브젝트: 코드로 이해하는 객체지향 설계[7주차_수요일] 494-504pg #요약 **Chapter 14. 일관성 있는 협력** 01. 핸드폰 과금 시스템 변경하기 02. 설계에 일관성 부여하기. 1) 조건 로직 대 객체 탐색 2) 캡슐화 다시 살펴보기 - 데이터 은닉 : 오직 외부에 공개된 메서드를 통해서만 객체의 내부에 접근할 수 있게 제한함으로써 객체 내부의 상태 구현을 숨기는 기법 - 캡슐화는 데이터 은닉 이상이다. - GOF의 조언에 따르면 캡슐화란 단순히 데이터를 감추는 게 아님. - 소프트웨어 안에서 변할 수 있는 모든 '개념'을 감추는 것임 - 캡슐화의 가장 대표적 예) 객체의 퍼블릭 인터페이스와 구현을 분리하는 것. - 자주 변경되는 내부 구현을 안정적인 퍼블릭 인터페이스 뒤로..