Clean Code | 클래스

목차

10장 클래스

• 클래스 체계
  • 캡슐화
• 클래스는 작아야 한다!
  • 단일 책임 원칙
  • 응집도 Cohesion
  • 응집도를 유지하면 작은 클래스 여럿이 나온다
• 변경하기 쉬운 클래스
  • 변경으로부터 거리

---

Intro

이전 챕터에서는 코드, 코드 블록, 함수 구현 방법과 함수 간의 관련 맺는 방식을 공부했다.
하지만 좀 더 높은 단계까지 신경 쓰지 않으면 깨끗한 코드를 얻기 어렵다.
그러니 클래스에 대해 자세히 알아두자.
 

클래스 체계

클래스는 아래와 같은 순서로 코드를 작성하자.
1) static 변수 : public → protected → package → private
2) instance 변수 :  public → protected → package → private
3) 생성자
4) 메서드 : (public → private → private) →  (public → private → private) → ...
 
public 메서드에서 호출되는 private 메서드는 바로 아래에 둔다.

public List<Cell> getFlaggedCells() {
    List<Cell> flaggedCells = new ArrayList();
 
    addFlaggedCells(flaggedCells);
 
    return flaggedCells;
}
 
private void addFlaggedCells(List<Cell> flaggedCells) {
    for (Cell cell : gameBoard)
        if (cell.isFlagged())
            flaggedCells.add(cell);
}

 

캡슐화

변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 하는 것은 아니다.
우리에게 테스트는 중요하므로 테스트를 위해 protected로 선언해서 접근을 허용하기도 한다.
하지만 비공개 상태를 유지할 온갖 방법을 강구하고, 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다.

클래스는 작아야 한다!

함수와 마찬가지로 클래스도 작아야 한다.
작아야 읽기 쉽고 변경하기 쉬운 코드가 된다.
 
클래스는 얼마나 작아야 할까?
 
클래스는 행 수로 크기를 재지 않고, 클래스가 맡은 책임을 센다.
 
클래스 내에 메서드가 많아도 책임이 1개이면 작은 클래스로 본다.
클래스 내에 메서드가 적어도 책임이 여러 개이면 큰 클래스로 본다.
 

클래스는 어떻게 작게 만들까?

 

SRP 원칙을 따르자

SRP(Single Responsibility Principle) 단일 책임 원칙: 클래스느 모듈을 변경할 이유가 하나뿐이어야 한다
 
큰 클래스 몇개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다.
작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해
시스템에 필요한 동작을 수행한다.
 
이외의 SOLID 원칙에 대해서 포스팅한 내용을 한번 읽어보면 좋겠다

SOLID 객체지향 5가지 원칙

 

응집도(cohesion) 를 높이자

응집도가 높다는 말은 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미이다.

• 클래스는 인스턴스 변수 수가 작아야 합니다.
• 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 합니다.
• 일반적으로 메서드가 변수를 더 많이 사용할수록 메서드와 클래스는 응집도가 더 높습니다.
• 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높습니다.

 

응집도를 유지하면 작은 클래스 여럿이 나온다

큰 함수를 작은 함수 여럿으로 나누기만 해도 클래스 수가 많아진다. 
 
예를 들어,
변수가 아주 많은 큰 함수가 하나 있다
--> 큰 함수 일부를 작은 함수로 빼내고 싶다
--> 빼내려는 코드가 큰 함수에 정의 된 변수를 많이 사용한다
--> 변수들을 새 함수에 인수로 넘겨야 하나? NO!
--> 변수들을 클래스 인스턴스 변수로 승격 시키면 인수가 필요없다. But! 응집력이 낮아짐
--> 몇몇 함수가 몇몇 인스턴스 변수만 사용한다면 독자적인 클래스로 분리해도 된다!

큰 함수를 작은 함수 여럿으로 쪼개다 보면 종종 작은 클래스 여럿으로 쪼갤 기회가 생긴다.
 

변경하기 쉬운 클래스

시스템은 변경이 불가피하다. 그리고 변경이 있을 때 마다 의도대로 동작하지 않을 위험이 따른다.
깨끗한 시스템은 클래스를 체계적으로 관리해 변경에 따르는 위험을 최대한 낮춘다.
 

변경으로부터 격리

OOP입문에서 concrete 클래스와 abstract 클래스가 있는데, concrete 클래스에 의존(상세한 구현에 의존)하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다.
그래서 인터페이스와 abstract 클래스를 사용해 구현이 미치는 영향을 격리시켜야 한다.

상세한 구현에 의존하는 코드는 테스트가 어려움.
그래서 추상화를 통해 테스트가 가능할 정도로 시스템의 결합도를 낮춤으로써
유연성과 재사용성도 더욱 높아진다.

결함도가 낮다는 말은 각 시스템 요소가 다른 요소로부터 그리고 변경으로부터 잘 격리되어있다는 뜻이다.
 

이 내용은 로버트 C.마틴 의 『Clean Code』 를 보고 정리하였습니다.