[Clean Code] 10장, 클래스

Clean Code

10장, 클래스

 

깨끗한 클래스란

 

 

1. 클래스 체계

 

- 클래스를 정의하는 표준 자바 관례: 추상화 단계로 순차적으로 내려감

정적(static), 공개(public) 상수 -> 정적 비공개(private) -> 비공개 인스턴스 변수 -> 공개 함수 -> 비공개 함수

 

 

캡슐화

변수와 유틸리티 함수는 가능한 숨기는 게 좋음

 

- protected: 변수나 유틸리티 함수에 테스트 코드가 접근 가능하도록 허용

why? 테스트가 매우 중요하기 때문

 

- 비공개 상태를 유지할 방법을 찾아야 함

 

 

2. 클래스는 작아야 함

 

- 클래스나 함수는 항상 '작게'가 기본 규칙이다.

 

- 클래스의 크기는 '책임'으로 나눔

ex. SuperDashboard는 약 70개의 method로 이루어짐: 책임이 너무 많음

 

- 클래스 이름: 클래스의 책임을 기술

➡️ Processor, Manager, Super 등의 단어는 클래스에 여러 책임을 안기게 된 것

 

- if, and, or, but을 사용하지 않아야 함

 

 

단일 책임 원칙(Single Responsibility Principle, SRP)

 

- 클래스나 모듈을 변경할 이유가 단 하나 뿐이어야 함

 

- '책임', 변경할 이유를 파악하려면 코드를 추상화 하기가 쉬워짐

 

- 위 SuperDashboard는 버전 정보를 다루는 메서드를 따로 빼내서 독자적인 클래스를 만들 수 있음

 

- 대부분 '돌아가는 프로그램'에 초점을 맞출 때, '깨끗하고 체계적인 소프트웨어'를 만들 수 있어야 함

 

- 작은 클래스 여러 개로 이루어진 시스템이 더욱 바람직 함, 하나의 클래스에 하나의 책임만

 

 

응집도(Cohesion)

 

- 응집도가 높은 클래스는 바람직하지 않음

 

- 클래스는 인스턴스 변수가 작아야 함, 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 함

> 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 높음

 

- 응집도가 높은 클래스를 선호하는 이유: 클래스에 속한 메서드와 변소가 서로 의존하며 논리적인 단위로 묶이기 때문

> 몇몇 메서드만이 사용하는 인스턴스 변수가 많아지면, 새로운 클래스로 쪼개서 응집도를 낮춰야 함

 

- 응집도를 유지하면 작은 클래스가 여러개가 나옴

> 큰 함수에 정의된 변수 넷을 사용하는 작은 함수를 쪼갤 때, 변수를 클래스 인스턴스 변수로 승격하는 경우가 생김 -> 인스턴스 변수가 늘어나게 되어 좋지 않음

 

- 큰 함수를 지속적으로 작은 함수로 쪼개야 함

ex. p179의 PrintPrimes.java
- 리팩터링을 하면서 프로그램 길이가 길어짐
1. 리팩터링한 프로그램은 좀 더 길고 서술적인 변수 이름 사용
2. 코드에 주석을 추가하는 수단으로 함수 선언과 클래스 선언을 활용
3. 가독성을 높이기 위해 공백과 형식을 추가

- 리팩터링 방법
1. 정확한 동작을 검증하는 테스트 슈트 작성
2. 한 번에 하나 씩 코드 변경
3. 코드를 변경하면서 테스트를 수행하여 프로그램과 동일하게 동작하는 지 확인

 

 

 

3. 변경하기 쉬운 클래스

 

- 변경 할 때마다 시스템이 의도대로 동작하지 않을 위험을 깨끗한 시스템은 클래스를 체계적으로 정리하여 위험을 낮춤

 

- 클래스에 많은 책임이 있을 때 -> extends를 이용하여 각 클래스를 기능 별로 단순하게 나눠야 함

🔗 상속

 

- 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조를 만들어야 함

 

 

변경으로부터 격리

 

- 구체적인 클래스: 상세한 구현(코드)를 포함

➡️ 구현이 바뀌면 위험에 빠짐

➡️ 테스트가 어려움

 

- 추상 클래스: 개념만 포함 ➡️ 영향 최소화

 

- 테스트가 가능할 정도로 시스템의 결합도를 낮춰서 유연성과 재사용성을 높혀야 함

 

- 결합도가 낮음 = DIP(Dependency Inversion Principle) 원칙을 따르는 클래스 생성

💡DIP: 클래스가 상세한 구현이 아니라 추상화에 의존해야 함

 

- 추상화로 구체적인 사실을 숨겨야 함