코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경 쓸지라도 좀 더 차원 높은 단계까지 신경 쓰지 않으면 깨끗한 코드를 얻기는 어렵다.
클래스 체계
👉 프로그램은 신문 기사처럼 읽히도록, 추상화 단계가 순차적으로 내려가도록 작성한다.
- 캡슐화
- 변수와 유틸리티 함수를 반드시 숨겨야하는 것은 ✕
- 하지만 비공개 상태를 유지할 방법을 강구
- 최후는
protected로 선언해 테스트 코드에 접근
클래스는 작아야 한다!
👉 클래스를 만들 때 기본 규칙은 작은 크기! 얼마나 작아야 하는지 알아보자.
- 클래스 이름은 해당 클래스 책임을 기술해야 한다. 작명은 클래스 크기를 줄이는 첫 번째 관문!
단일 책임 원칙 (SRP)
- 🔎 클래스나 모듈을 변경할 이유와 맡은 책임이 단 하나뿐이여야 한다는 원칙
변경할 이유를 파악하다 보면 코드를 추상화하기 쉬워진다. - 작은 클래스는 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행하며 이것이 바람직하다.
- 🔎 클래스나 모듈을 변경할 이유와 맡은 책임이 단 하나뿐이여야 한다는 원칙
응집도 (Cohesion)
- 변수 사용량↑ = 응집도↑
= 클래스에 속한 메서드와 변수의 의존성↑, 논리적인 단위로 묶임 - 함수를 작게, 매개변수 목록을 짧게!
- 몇몇 메서드만이 사용하는 인스턴트 변수가 많아지게 되면 새로운 클래스로 쪼개라.
- 변수 사용량↑ = 응집도↑
응집도를 유지하면 작은 클래스 여럿이 나온다.
- 함수로 쪼개면 응집력을 잃는다. 그렇다면 작은 클래스로 쪼개라!
저자가 추천하는 리팩터링 방법
- 1) 원래 프로그램의 정확한 동작을 검증하는 테스트 슈트를 작성
- 2-1) 한 번에 하나씩 수 차례에 걸쳐 조금씩 코드를 변경
- 2-2) 코드를 변경할 때마다 테스트 수행
- 3) 최종 프로그램!!!!
변경하기 쉬운 클래스
👉 깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다. 체계적으로 정리 = 서로 분리된 클래스
- 개선에 뛰어드는 계기는 시스템이 변해서여야 한다.
- 구조적인 관점에서 SRP(단일 책임 원칙)과 OCP(개방 폐쇄 원칙)을 위반하는지 체크하여 개선한다.
- 변경으로부터 격리한다.
- 변경은 필연적인 것. 시스템의 결합도를 낮춰 유연성과 재사용성을 높이자!
- 결합도↓ = 각 시스템 요소가 서로 잘 격리된 것
- 결합도를 최소화하면 DIP를 따르는 클래스가 나옴
🔎 DIP(Dependency Inversion Principle) : 의존관계 역전 원칙. 소프트웨어 모듈을 분리하는 특정 형식.
인상 깊었던..
우리들 대다수는 두뇌 용량에 한계가 있어 '깨끗하고 체계적인 소프트웨어'보다 '돌아가는 소프트웨어'에 초점을 맞춘다.
문제는 우리들 대다수가 프로그램이 돌아가면 일이 끝났다고 여기는 데 있다.
규모가 어느 수준에 이르는 시스템은 논리가 많고도 복잡하다. 이런 복잡성을 다루려면 체계적인 정리가 필수다. 그래야 개발자가 무엇이 어디에 있는지 쉽게 찾는다.
노력하는 초보 개발자