3 주차
화, 수 | Assignment #15
10장. 클래스
📘 책에서 기억하고 싶은 내용
- 클래스 체계 (p.172)
- 작성 순서
- 정적 공개 상수
- 정적 비공개 상수
- 비공개 인스턴스 변수
- 공개 함수
- 비공개 함수 (자신을 호출하는 공개 함수 직후에 삽입)
- 캡슐화
- 테스트 코드가 함수를 호출하거나 변수를 사용해야 한다면 그 함수나 변수를
protected
로 선언하거나 패키지 전체로 공개 가능하지만, 언제나 최후의 수단이어야 한다.
- 클래스는 작아야 한다! (p.172)
- 클래스명 작명
- 간결한 이름이 떠오르지 않는다면 클래스 크기가 큰 것이다.
- 클래스명이 모호하다면 클래스의 책임이 너무 많은 것이다.
- 클래스 설명은
if
, and
, or
, but
을 사용하지 않고 25단어 내외로 가능해야 한다.
- 단일 책임 원칙 (SRP, Single Responsibility Principle)
- 클래스나 모듈을 변경할 이유가 단 하나여야 한다는 원칙
- 돌아가는 소프트웨어도 중요하지만, 문제는 프로그램이 돌아가면 일이 끝났다고 여기는 것이다.
- 작은 서랍 VS 큰 서랍 : 작은 서랍처럼 컴포넌트를 명확하게 나누어 사용하는 것이 관리에 용이하다.
- 응집도 (Cohesion)
- 응집도가 높다는 뜻은 클래스에 속한 메소드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미이다.
- 클래스는 인스턴스 수가 적고, 각 클래스 메소드는 클래스 인스턴스 변수를 하나 이상 사용하는 것이 좋다.
- 함수를 작고 매개변수 목록을 짧게 개발하다보면 몇몇 메소드만 사용하는 인스턴스 변수가 많아지게 되는데, 이는 클래스를 쪼개야 한다는 신호이다.
- 변경하기 쉬운 클래스 (p.185)
- 깨끗한 시스템은 클래스를 체계적으로 정리해 사이드 이펙트의 위험을 낮춘다.
- 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지 않는다.
- 변경으로부터 격리
- 상세한 구현에 의존하는 클라이언트 클래스는 구현이 변경되면 리스크가 발생한다.
- 결합도가 낮다는 뜻은 각 시스템 요소가 다른 요소로부터 그리고 변경으로부터 격리되어 있다는 의미이다.
- 결합도를 최소로 줄이면 자연스럽게
DIP
원칙을 따르게 된다.
🤔 소감 및 생각
- 어렵고 한 눈에 들어 오지 않는 코드를 볼 때마다 '어디서부터 어떻게 고쳐나가야 할까..?'란 생각을 자주 했는데 그 질문에 대한 답을 이번 챕터를 읽으며 정리할 수 있었던 것 같다. 막연히
깨끗하고 깔끔한 코드
가 아닌 객체지향 설계 원칙을 따르는 코드
가 결국에 깔끔하고 유지보수가 용이한 코드임을 알 수 있었다.
- 끝나지 않을 것 같던 3주 동안의 노개북 북클럽도 이번이 벌써 일정상 마지막 챕터이다. 개인적으로 남은 부분도 10장까지의 내용만큼 중요해보인다고 생각해서 2주 정도 더 지금처럼 읽어보려고 한다. 끝날 그날까지,,,, 화이팅,,,
🔍 새롭게 또는 다시 알게 된 내용