이정우

1. 📌 핵심 개념 정리

각자 해당 챕터에서 중요하다고 느낀 개념이나 아이디어를 간략하게 정리하고 개선 전, 후에 대한 예시 코드를 비교하며 개념을 설명합니다.

클래스 체계
- 변수목록
  - 1️⃣ 정적 공개 상수
  - 2️⃣ 정적 비공개 변수
  - 3️⃣ 비공개 인스턴스
  - 4️⃣ 공개 변수 (필요한 경우 거의 없음)
- 공개 함수
- 비공개 함수
- 추상화 단계가 순차적으로 내려가기에 프로그램은 신문기사처럼 읽힌다.
- 캡슐화
  - 변수와 유틸리티 함수는 가능한 공개x
  - 패키지 내 테스트코드가 함수 호출, 변수 사용 시에는 함수나 변수를 protected선언 하거나 패키지 전체로 공개
  - 그 전에 비공개 상태를 유지할 방법을 강구, 캡슐화를 풀어주는 결정은 최후의 수단.

클래스는 작아야 한다!
- 클래스 설계 시 작게 가 기본 규칙
- 클래스 크기의 척도는 맡은 책임 이다.
- 클래스명은 클래스 책임을 기술해야 한다.
- 클래스 설명은 if, and, or, but을 사용하지 않은 25단어 내외
- 단일 책임 원칙 (SRP)
  - 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다.
  - 객체 지향 설계에서 가장 중요한 규칙이지만, 가장 무시되는 규칙 중 하나이다.
  - 적은 양의 큰 클래스가 아닌 많은 양의 작은 클래스를 지향해야 한다.
- 응집도 Cohesion)
  - 클래스의 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다. => 응집도가 높다.
  - 클래스는 인스턴스 변수 수가 적어야 한다.
  - 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다.
  - 일반적으로 메서드가 변수를 더 많이 사용 할수록 메서드와 클래스는 응집도가 높다.
  - 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높다.
  - 응집도가 가장 높은 클래스는 가능하지도, 바람직하지도 않지만 응집도가 높은 클래스를 선호한다.
- 응집도를 유지하면 작은 클래스 여럿이 나온다.
  - 클래스가 응집력을 잃으면 쪼개라
  - 큰 함수를 쪼개는 과정에서 프로그램의 체계가 잡히고 구조가 투명해진다.

변경하기 쉬운 클래스
- 대다수 시스템은 지속적인 변경 -> 의도와 무관한 동작의 위험 -> 깨끗한 시스템은 변경에 수반하는 위험을 낮춘다.
- OCP
  - 클래스는 화갖ㅇ에 개방적이고 수정에 폐쇄적이어야 한다.
- 코드 수정 시 건드릴 코드가 최소인 시스템 구조가 바람직하다.
- 변경으로부터 격리
  - 요구사항은 변하기 마련이고, 이에 따라 코드도 변한다.
  - 상세한 구현에 의존하는 클라이언트 클래스는 구현이 빠지면 위험에 빠진다.
  - 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 경리한다.
  - 결합도가 낮다는 것은 각 시스템 요소가 다른 요소, 변경으로부터 잘 격리되어 있다는 의미이다.
  - 시스템 요소가 서로 잘 격리되어 있으면 각 요소를 이해하기도 쉬워진다.
  - DIP
    - 결합도를 최소하하면 자연스럽게 따라온다.
    - 본질적으로는 클래스가 상세 구현이 나닌 추상화에 의존해야 한다는 원칙 .
      .

개선 전 코드

개선 전 코드의 문제점을 작성합니다.

개선 후 코드

개선 후의 코드에 대한 설명을 작성합니다.

책을 읽으며 이해하기 어려웠던 개념이나 명확하지 않았던 내용을 정리합니다.

개념 또는 원칙의 이름
- 어려웠던 부분
  해당 개념이 헷갈리거나 명확하지 않았던 점을 구체적으로 설명합니다.
- 궁금한 점
  해당 개념이 어떤 원리로 동작하는지, 실무에서 어떻게 활용되는지 등을 질문 형태로 정리합니다.

관련된 자료가 있다면 공유하고, 더 깊이 논의하고 싶은 아이디어나 의견을 정리합니다.