코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경 쓸지라도 좀 더 차원 높은 단계까지 신경 쓰지 않으면 깨끗한 코드를 얻기는 어렵다

클래스 체계

클래스를 정의하는 표준 자바 관례에 따르면

• 변수 목록
  1. 정적 공개 상수 : static public let
  2. 정적 비공개 변수 : static private var
  3. 비공개 인스턴스 변수 : private var
  4. 공개 변수 (필요한 경우는 거의 없다)
• 공개 함수
• 비공개 함수 (자신을 호출하는 공개 함수 직후)

추상화단계가 순차적으로 내려간다. 그래서 프로그램은 신문 기사처럼 읽힌다

캡슐화

변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없다. 때로는 변수나 유틸리티 함수는 protected로 선언해 테스트 코드에 접근을 허용하기도 한다

같은 패키지 안에서 테스트 코드가 함수를 호출하거나 변수를 사용해야 한다면 그 함수나 변수를 protected로 선언하거나 패키지 전체로 공개한다. 하지만 그 전에 비공개 상태를 유지할 온갖 방법을 강구한다

캡슐화를 풀어주는 결정은 언제나 최후의 수단이다

클래스는 작아야 한다!

함수에서와 마찬가지도 되풀이된다. 클래스도 역시나 작아야 한다

함수는 물리적인 행 수로 크기를 측정했지만 클래스는 맡은 책임을 센다

메서드 수가 작아도 책임이 많다면 괜찮지 않다

클래스 이름은 해당 클래스 책임을 기술해야 한다. 클래스 이름이 모호하다면 필경 클래스 책임이 너무 많아서다

클래스 이름에 Processor, Manager, Super 등과 같이 모호한 단어가 있다면 클래스에다 여러 책임을 떠안겼다는 증거다. 또한, 클래스 설명은 만일(if), 그리고(and), -(하)며(or), 하지만(but) 을 사용하지 않고서 25단어 내외로 가능해야 한다