🧭 방향

• 목표 : 그룹 스터디 진행을 효과적으로 관리하기 위해 저장소를 운영한다.

⌚ 매주 주말 1회 1시간

• 장소 : 디스코드

🤔 방식

• 1️⃣ object 프로젝트를 자신의 계정으로 fork합니다.
• 2️⃣ fork한 repository를 개인 컴퓨터에 clone합니다.
• 3️⃣ 매 주 목표의 독서량을 읽고 정리하여 코드 저장(commit) & 개인 원격 저장소 저장(push)를 합니다.
• 4️⃣ github에서 PR(pull request)를 작성합니다.
  • PR 출발지는 fork한 자신의 저장소의 3️⃣번에서 생성한 branch로 합니다.
  • ex) object:master <- object:origin/master
• 5️⃣ 커밋 메시지를 작성합니다. PR 규칙 및 Commet Message 규칙 참고
• 6️⃣ PR들을 merge합니다.
• 7️⃣ 독서량에서 읽었던 내용 중 면접 질문을 만들거나 깨달은 점 의문이 들었던점을 마크다운으로 정리하여 공유합니다.
• 8️⃣ 이후, 각자 본인의 폴더에 장.별로 구분하여 동일한 방식(1-6)으로 코드를 관리하며 스터디를 완료합니다.

패키지 구성 가이드

Chapter 1
ㄴ 01. 티켓판매 애플리케이션 구현하기
  ㄴ 우연.md

🤙🏻 PR 규칙 및 Commit Message 규칙

• Pull Request (공용 저장소)

  • 이름 장 제목
  • ex) docs: 우연 1장 완료

• Commit Message (개인 저장소)

  • 장 제목
  • ex) 1장 ~~ 완료

목차

▣ 들어가며: 프로그래밍 패러다임

1. 패러다임의 시대
2. 프로그래밍 패러다임

▣ 1장: 객체, 설계

1. 티켓 판매 애플리케이션 구현하기
2. 무엇이 문제인가

• 예상을 빗나가는 코드
• 변경에 취약한 코드

3. 설계 개선하기

• 자율성을 높이자
• 무엇이 개선됐는가
• 어떻게 한 것인가
• 캡슐화와 응집도
• 절차지향과 객체지향
• 책임의 이동
• 더 개선할 수 있다
• 그래, 거짓말이다!

4. 객체지향 설계

• 설계가 왜 필요한가
• 객체지향 설계

▣ 2장: 객체지향 프로그래밍

1. 영화 예매 시스템

• 요구사항 살펴보기

2. 객체지향 프로그래밍을 향해

• 협력, 객체, 클래스
• 도메인의 구조를 따르는 프로그램 구조
• 클래스 구현하기
• 협력하는 객체들의 공동체
• 협력에 관한 짧은 이야기

3. 할인 요금 구하기

• 할인 요금 계산을 위한 협력 시작하기
• 할인 정책과 할인 조건
• 할인 정책 구성하기

4. 상속과 다형성

• 컴파일 시간 의존성과 실행 시간 의존성
• 차이에 의한 프로그래밍
• 상속과 인터페이스
• 다형성
• 인터페이스와 다형성

5. 추상화와 유연성

• 추상화의 힘
• 유연한 설계
• 추상 클래스와 인터페이스 트레이드오프
• 코드 재사용
• 상속
• 합성

▣ 3장: 역할, 책임, 협력

1. 협력

• 영화 예매 시스템 돌아보기
• 협력
• 협력이 설계를 위한 문맥을 결정한다

2. 책임

• 책임이란 무엇인가
• 책임 할당
• 책임 주도 설계
• 메시지가 객체를 결정한다
• 행동이 상태를 결정한다

3. 역할

• 역할과 협력
• 유연하고 재사용 가능한 협력
• 객체 대 역할
• 역할과 추상화
• 배우와 배역

▣ 4장: 설계 품질과 트레이드오프

1. 데이터 중심의 영화 예매 시스템

• 데이터를 준비하자
• 영화를 예매하자

2. 설계 트레이드오프

• 캡슐화
• 응집도와 결합도

3. 데이터 중심의 영화 예매 시스템의 문제점

• 캡슐화 위반
• 높은 결합도
• 낮은 응집도
• 캡슐화를 지켜라

4. 자율적인 객체를 향해

• 스스로 자신의 데이터를 책임지는 객체
• 캡슐화 위반

5. 하지만 여전히 부족하다

• 높은 결합도
• 낮은 응집도
• 데이터 중심 설계는 객체의 행동보다는 상태에 초점을 맞춘다

6. 데이터 중심 설계의 문제점

• 데이터 중심 설계는 객체를 고립시킨 채 오퍼레이션을 정의하도록 만든다

▣ 5장: 책임 할당하기

1. 책임 주도 설계를 향해

• 데이터보다 행동을 먼저 결정하라
• 협력이라는 문맥 안에서 책임을 결정하라
• 책임 주도 설계

2. 책임 할당을 위한 GRASP 패턴

• 도메인 개념에서 출발하기
• 정보 전문가에게 책임을 할당하라
• 높은 응집도와 낮은 결합도
• 창조자에게 객체 생성 책임을 할당하라

3. 구현을 통한 검증

• DiscountCondition 개선하기
• 타입 분리하기
• 다형성을 통해 분리하기
• 변경으로부터 보호하기
• Movie 클래스 개선하기
• 변경과 유연성

4. 책임 주도 설계의 대안

• 메서드 응집도
• 객체를 자율적으로 만들자

▣ 6장: 메시지와 인터페이스

1. 협력과 메시지

• 클라이언트- 서버 모델
• 메시지와 메시지 전송
• 메시지와 메서드
• 퍼블릭 인터페이스와 오퍼레이션
• 시그니처

2. 인터페이스와 설계 품질

• 묻지 말고 시켜라
• 의도를 드러내는 인터페이스
• 함께 모으기

3. 원칙의 함정

• 디미터 법칙은 하나의 도트(.)를 강제하는 규칙이 아니다
• 결합도와 응집도의 충돌

4. 명령- 쿼리 분리 원칙

• 반복 일정의 명령과 쿼리 분리하기
• 명령- 쿼리 분리와 참조 투명성
• 책임에 초점을 맞춰라

▣ 7장: 객체 분해

1. 프로시저 추상화와 데이터 추상화
2. 프로시저 추상화와 기능 분해

• 메인 함수로서의 시스템
• 급여 관리 시스템
• 급여 관리 시스템 구현
• 하향식 기능 분해의 문제점
• 언제 하향식 분해가 유용한가?

3. 모듈

• 정보 은닉과 모듈
• 모듈의 장점과 한계

4. 데이터 추상화와 추상 데이터 타입

• 추상 데이터 타입

5. 클래스

• 클래스는 추상 데이터 타입인가?
• 추상 데이터 타입에서 클래스로 변경하기
• 변경을 기준으로 선택하라
• 협력이 중요하다

▣ 8장: 의존성 관리하기

1. 의존성 이해하기

• 변경과 의존성
• 의존성 전이
• 런타임 의존성과 컴파일타임 의존성
• 컨텍스트 독립성
• 의존성 해결하기

2. 유연한 설계

• 의존성과 결합도
• 지식이 결합을 낳는다
• 추상화에 의존하라
• 명시적인 의존성
• new는 해롭다
• 가끔은 생성해도 무방하다
• 표준 클래스에 대한 의존은 해롭지 않다
• 컨텍스트 확장하기
• 조합 가능한 행동

▣ 9장: 유연한 설계

1. 개방- 폐쇄 원칙

• 컴파일타임 의존성을 고정시키고 런타임 의존성을 변경하라
• 추상화가 핵심이다

2. 생성 사용 분리

• FACTORY 추가하기
• 순수한 가공물에게 책임 할당하기

3. 의존성 주입

• 숨겨진 의존성은 나쁘다

4. 의존성 역전 원칙

• 추상화와 의존성 역전
• 의존성 역전 원칙과 패키지

5. 유연성에 대한 조언

• 유연한 설계는 유연성이 필요할 때만 옳다
• 협력과 책임이 중요하다

▣ 10장: 상속과 코드 재사용

1. 상속과 중복 코드

• DRY 원칙
• 중복과 변경
• 상속을 이용해서 중복 코드 제거하기
• 강하게 결합된 Phone과 NightlyDiscountPhone

2. 취약한 기반 클래스 문제

• 불필요한 인터페이스 상속 문제
• 메서드 오버라이딩의 오작용 문제
• 부모 클래스와 자식 클래스의 동시 수정 문제

3. Phone 다시 살펴보기

• 추상화에 의존하자
• 차이를 메서드로 추출하라
• 중복 코드를 부모 클래스로 올려라
• 추상화가 핵심이다
• 의도를 드러내는 이름 선택하기
• 세금 추가하기

4. 차이에 의한 프로그래밍

▣ 11장: 합성과 유연한 설계

1. 상속을 합성으로 변경하기

• 불필요한 인터페이스 상속 문제: java.util.Properties와 java.util.Stack
• 메서드 오버라이딩의 오작용 문제: InstrumentedHashSet
• 부모 클래스와 자식 클래스의 동시 수정 문제: PersonalPlaylist

2. 상속으로 인한 조합의 폭발적인 증가

• 기본 정책과 부가 정책 조합하기
• 상속을 이용해서 기본 정책 구현하기
• 기본 정책에 세금 정책 조합하기
• 기본 정책에 기본 요금 할인 정책 조합하기
• 중복 코드의 덫에 걸리다

3. 합성 관계로 변경하기

• 기본 정책 합성하기
• 부가 정책 적용하기
• 기본 정책과 부가 정책 합성하기
• 새로운 정책 추가하기
• 객체 합성이 클래스 상속보다 더 좋은 방법이다

4. 믹스인

• 기본 정책 구현하기
• 트레이트로 부가 정책 구현하기
• 부가 정책 트레이트 믹스인하기
• 쌓을 수 있는 변경

▣ 12장: 다형성

1. 다형성
2. 상속의 양면성

• 상속을 사용한 강의 평가
• 데이터 관점의 상속
• 행동 관점의 상속

3. 업캐스팅과 동적 바인딩

• 같은 메시지, 다른 메서드
• 업캐스팅
• 동적 바인딩

4. 동적 메서드 탐색과 다형성

• 자동적인 메시지 위임
• 동적인 문맥
• 이해할 수 없는 메시지
• self 대 super

5. 상속 대 위임

• 위임과 self 참조
• 프로토타입 기반의 객체지향 언어

▣ 13장: 서브클래싱과 서브타이핑

1. 타입

• 개념 관점의 타입
• 프로그래밍 언어 관점의 타입
• 객체지향 패러다임 관점의 타입

2. 타입 계층

• 타입 사이의 포함관계
• 객체지향 프로그래밍과 타입 계층

3. 서브클래싱과 서브타이핑

• 언제 상속을 사용해야 하는가?
• is- a 관계
• 행동 호환성
• 클라이언트의 기대에 따라 계층 분리하기
• 서브클래싱과 서브타이핑

4. 리스코프 치환 원칙

• 클라이언트와 대체 가능성
• is- a 관계 다시 살펴보기
• 리스코프 치환 원칙은 유연한 설계의 기반이다
• 타입 계층과 리스코프 치환 원칙

5. 계약에 의한 설계와 서브타이핑

• 서브타입과 계약

▣ 14장: 일관성 있는 협력

1. 핸드폰 과금 시스템 변경하기

• 기본 정책 확장
• 고정요금 방식 구현하기
• 시간대별 방식 구현하기
• 요일별 방식 구현하기
• 구간별 방식 구현하기

2. 설계에 일관성 부여하기

• 조건 로직 대 객체 탐색
• 캡슐화 다시 살펴보기

3. 일관성 있는 기본 정책 구현하기

• 변경 분리하기
• 변경 캡슐화하기
• 협력 패턴 설계하기
• 추상화 수준에서 협력 패턴 구현하기
• 구체적인 협력 구현하기
• 협력 패턴에 맞추기
• 패턴을 찾아라

▣ 15장: 디자인 패턴과 프레임워크

1. 디자인 패턴과 설계 재사용

• 소프트웨어 패턴
• 패턴 분류
• 패턴과 책임- 주도 설계
• 캡슐화와 디자인 패턴
• 패턴은 출발점이다

2. 프레임워크와 코드 재사용

• 코드 재사용 대 설계 재사용
• 상위 정책과 하위 정책으로 패키지 분리하기
• 제어 역전 원리

▣ 마치며: 나아가기

▣ 부록A: 계약에 의한 설계

1. 협력과 계약

• 부수효과를 명시적으로
• 계약

2. 계약에 의한 설계

• 사전조건
• 사후조건
• 불변식

3. 계약에 의한 설계와 서브타이핑

• 계약 규칙
• 가변성 규칙
• 함수 타입과 서브타이핑

▣ 부록B: 타입 계층의 구현

• 클래스를 이용한 타입 계층 구현
• 인터페이스를 이용한 타입 계층 구현
• 추상 클래스를 이용한 타입 계층 구현
• 추상 클래스와 인터페이스 결합하기
• 덕 타이핑 사용하기
• 믹스인과 타입 계층

▣ 부록C: 동적인 협력, 정적인 코드

1. 동적 모델과 정적 모델

• 행동이 코드를 결정한다
• 변경을 고려하라

2. 도메인 모델과 구현

• 도메인 모델에 관하여
• 몬스터 설계하기
• 행동과 변경을 고려한 도메인 모델
• 분석 모델, 설계 모델, 그리고 구현 모델