[클린코드] TIL - 10장 클래스

🖤 TIL (Today I Learned)

• 프로그램은 신문처럼 읽힌다 (추상화 단계가 순차적으로 내려감)
  • 가장 먼저 변수 목록 public static -> private static -> pirvate instance 변수
  • 공개함수 -> 비공개 함수는 자신을 호출하는 공개 함수 직후에
• 클래스는 작아야 함 - 크기
  • 물리적 행 수
  • 맡은 책임
    • 클래스의 이름은 해당 클래스 책임을 기술해야 함 (Processor, Manager, Super 사용 금지)
    • 클래스의 설명은 "if", "and", "or", "but"을 사용하지 않고저 25단어 내외로 가능해야 함
  • 단일 책임 원칙(SRP)
    • 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 함
  • 응집도 (Cohesion)
    • 메서드와 변수가 논리적인 단위로 묶임 (이상적이라고 생각) 
    • 클래스는 인스턴스 변수 수가 작아야 함. 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 함
    • 메서드가 변수를 더 많이 사용할 수록 메서드 - 클래스의 응집도가 높음.
    • 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높음
    • 응집도 있게 함수를 여럿으로 나누다보면 몇몇 함수에서 사용하지 않는 변수가 생김 -> 클래스를 나눔 -> 응집도가 높아짐
  • 변경하기 쉬운 클래스
    • 깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춤
    • 확장에 닫히게 하는 방법
      • 다형성(abstract - override)을 이용하여 추가가 필요할 때 기존의 클래스의 변경없이 추가할 수 있음 
      • 각 클래스 내부가 단순해짐
    • 변경으로부터 격리 
      • 상세한 구현에 의존하는 코드는 테스트가 어려움
      • 직접 호출 대신 인터페이스 생성 후 메서드를 선언
      • 테스트가 가능할 정도로 시스템의 결합도를 낮추면 유연성과 재사용성이 높아짐 (DIP와 연관)

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

// 구현 클래스
public Portfolio {
	private StockExchange exchange;
    public Portfolio(StockExchange exchange) { // 이렇게 Interface를 넣어 mocking을 쉽게할 수 있도록
    	this.exchange = exchage;
    }
}

// 테스트 코드
public class PortfolioTest {
	private FixedStockExchangeStub exchage; // test용 stub
    private Portfolio portfolio;
    
    @Before
    protected void setUp() throws Exception {
    	exchange = new FixedStockExchageStub(); // 인터페이스이므로 쉽게 테스트 코드 작성 가능
        exchange.fix("MSFT", 100);
        portfolio = new Portfolio(exchage);
    }
    
    @Test
    public void GivenFiveMSFTTotalShouldBe500() throws Exception {
    	portfolio.add(5, "MSFT");
        Assert.assertEquals(500, portfolio.value);
    }
}

 

❤️ 오늘 읽은 범위

10장 클래스

🤍 기록

- 인상에 남은 구절

a: "단일 책임 클래스가 많아지면 큰 그림을 이해하기 어려워진다. 클래스들을 수 없이 넘나 들어야 한다."
b:  "도구 상자를 어떻게 관리하고 싶은지? 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 넣고 싶은가? 큰 서랍 몇 개를 두고 모두를 던져 넣고 싶은가?"
-> 변경을 가할 때 직접 영향이 미치는 컴포넌트만 이해해도 충분. 당장 알 필요가 없는 사실까지 알아야할 이유가 없음

새로운 아키텍처를 짜면서 팀원들과 가장 많이 나눴던 고민거리였다. 

혹자에게는 클래스를 길게 보는 것 자체가 리소스 낭비이고, 또 다른이에게는 클래스를 많이 만들어서 컴파일하고, 넘어다니는게 더 리소스 낭비처럼 느껴진다고 한다.

물론 프로젝트마다 정답은 없고, 코드가 많아지고 로직이 복잡해질수록 보기 어려워지는건 어쩔수 없는 문제라고 생각한다. 이 책을 읽으며 느낀건 클래스에 많이 넣느냐, 잘게 나누냐의 차이보다도 그 클래스의 단위가 역할대로 잘 나뉘어져 있느냐가 중요하다는 생각이 든다.