[클린 코드] 10장. 클래스

1. 클래스는 작아야 한다!

• 클래스가 맡은 책임이 적어야 한다.
• 클래스 이름은 해당 클래스 책임을 기술해야 한다. 클래스 이름을 짓기 어렵다면, 클래스 책임이 너무 많아서일 것이다.

1-1. 단일 책임 원칙

• 클래스나 모듈을 변경할 이유가 하나뿐이어야 한다.
• 작은 클래스는 각자 맡은 책임이 하나이고, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.

1-2. 응집도

• 클래스는 인스턴스 변수의 수가 작아야 하고, 메서드는 인스턴스 변수를 하나 이상 사용해야 한다.
• 메서드가 변수를 많이 사용할수록 클래스의 응집도는 높다.
• 응집도를 유지하면 작은 클래스가 여러 개 나온다.
  • 몇몇 메서드만이 인스턴스 변수를 많이 사용하는 경우가 발생한다면, 클래스를 쪼개야 하는 신호이다!

1-3. 변경하기 쉬운 클래스 (OCP: Open Closed Principle)

• 확장에 개방적이고, 수정에 폐쇄적이어야 한다.
• 새 기능을 추가하거나, 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다.
  • 이상적으로, 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지 않는다.

1-4. 변경으로부터 거리 (DIP: Dependency Inversion Principle)

• 클래스는 상세한 구현 클래스가 아니라 추상화된 클래스에 의존해야 한다.
  • 각 시스템 요소가 다른 요소 및 변경으로부터 잘 격리되도록 결합도를 낮추어야 한다.

public interface StockExchange {
 Money currentPrice(String symbol);
}

// 아래 Portfolio 클래스는 외부 Tokyo의 StockExchange API (TokyoStockExchange)를 사용해 
// 포트폴리오 값을 계산한다.
// 만약, API 가 다른 나라의 StockExchange API로 여러 번 바뀐다면 테스트 코드를 짜기가 쉽지 않다.
// 따라서 아래와 같이 StockExchange 인터페이스를 참조자로 인수로 받도록 한다.
public Portfolio {
 private StockExchange exchange;
 public Portfolio(StockExchange exchange) {
  this.exchange = exchange;
 }
 
 ...
}

 

• TokyoStockExchange라는 상세한 구현 클래스가 아니라 StockExchange 인터페이스에 의존함으로써, 결합도를 줄일 수 있고, 테스트 코드를 작성하기도 쉬워진다.