이정우

1. 📌 핵심 개념 정리

✅ 요약하기

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

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

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

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

2. 🤔 이해가 어려운 부분

🔍 질문하기

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

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

3. 📚 참고 사항

📢 논의하기

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

1. 관련 자료 공유
   • 추가 자료
     관련 블로그 글이나 공식 문서 링크를 제공합니다.

2. 논의하고 싶은 주제
   • 주제
     응집도를 판단하는 기준? 어느정도가 되어야 응집도가 높다/낮다를 판단하고 수정할 수 있을까?
   • 설명
     응집도(Cohesion)를 판단 기준
     • 모듈 내부의 기능들이 얼마나 밀접하게 관련되어 있는가?
     • 변경의 이유 서로 연관성이 없는 기능이나 데이터가 하나의 클래스 안에 뭉쳐 있는가?
     • 모듈이 명확하고 일관된 책임을 가지고 있는가?
     • 메서드 수준, 함수 수준, 모듈 수준.
     • 응집도와 대비되는 개념으로 결합도(Coupling)가 있다.
       • 결합도는 소프트웨어 시스템에서 모듈 간의 상호 의존도를 측정한 것으로, 모듈이 밀접하게 연결되어 있는 정도를 나타낸다.
       • 결합도가 높으면 변경하고 검토해야 하는 모듈 수가 많아지는 단점이 있다.