클래스 체계
클래스를 정의하는 표준 자바 관례에 따르면 클래스 내부의 상태와 행위는 다음과 같은 순서로 열거되 있어야 한다.
1. static public 상수
2. static private 변수
3. 비공개 인스턴스
4. public 메서드
5. private 메서드(자신을 호출하는 public 메서드 직후에 들어간다 -> 추상화 단계가 순차적으로 내려간다)
캡슐화
상태와 구현은 되도록이면 객체 내부에 숨겨야 한다. 물론 구현을 protected로 선언해 테스트 코드에 접근을 허용하는 경 우도 있지만 이들의 캡슐화를 해제하기 전에 다른 방법이 있는지를 먼저 고려해야 한다.
클래스는 작아야 한다
함수와 마찬가지로 클래스 역시 작아야 한다. 다만 함수의 크기를 물리적인 행으로 특정했다면 클래스는 책임을 단위로 크기를 측정한다.
클래스 이름은 해당 클래스 책임을 기술해야 한다. 그래야 클래스의 크기가 줄어든다. 클래스이름이 모호하면 클래스의 책임이 많다는 의미고 이름이 떠오르지 않으면 클래스 크기가 너무 크다는 의미다.
클래스를 설명할때 만일(if), 그리고(and), (하)며(or), 하지만(but)을 사용하지 않고 25단어 내외로 설명할 수 있어야 한다.
단일 책임 원칙(Single Responsibility Principle)
클래스나 모듈을 변경해야 하는 이유가 단 하나만 존재해야 한다는 원칙이다. 이른 지킴으로서 작은 클래스를 만들 수 있 다.
응집도(Cohesion)
클래스는 인스턴스 변수 수가 작아야 한다. 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다. 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 높다.
응집도가 높다는 것은 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미이다.
'함수를 작게, 매개변수 목록을 짧게'라는 말을 따르다 보면 때때로 일부 메서드만 사용하는 인스턴스 변수가 많아진다. 이 럴때는 새로운 클래스로 쪼개야 한다.
응집도를 유지하면 작은 클래스 여럿이 나온다.
큰 함수를 작은 함수 여럿으로 나누기만 해도 클래스 수가 많아진다. 예를 들어, 변수가 아주 많은 큰 함수가 있고 이함수 를 A라 하자. A함수의 일부를 쪼개서 다른 함수 B를 만들고 싶은데 B는 A에 정의된 변수 4개를 사용한다 하자. 그러면 B에 넘겨야 하는 변수는 몇개일까?
정답은 그냥 변수들은 클래스 인스턴스 변수로 승격하면 된다. 하지만 이 방법은 몇몇 메서드만 사용하는 몇몇 상태를 만 들기 때문에 클래스가 응집력을 잃는다. 여기서 일부 메서드만 일부 상태를 사용한다면 이들을 별도의 클래스로 만들면 된 다. 그러면 프로그램의 체계가 점차 잡히고 구조가 투명해 진다.
변경하기 쉬운 클래스
대다수 시스템은 지속적인 변경이 가해진다. 그리고 변경은 버그를 야기할 가능성을 가진다. 깨끗한 시스템은 클래스를 채계적으로 정리하고 변경에 수반하는 위험을 낮춘다.
변경으로부터 격리
요구사항은 언제나 변한다. 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험하다. 따라서 구현이 아닌 퍼블릭 인터페이스에 의존하게 설계해야 한다.
출처 - 클린 코드