🖤 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: "도구 상자를 어떻게 관리하고 싶은지? 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 넣고 싶은가? 큰 서랍 몇 개를 두고 모두를 던져 넣고 싶은가?"
-> 변경을 가할 때 직접 영향이 미치는 컴포넌트만 이해해도 충분. 당장 알 필요가 없는 사실까지 알아야할 이유가 없음
새로운 아키텍처를 짜면서 팀원들과 가장 많이 나눴던 고민거리였다.
혹자에게는 클래스를 길게 보는 것 자체가 리소스 낭비이고, 또 다른이에게는 클래스를 많이 만들어서 컴파일하고, 넘어다니는게 더 리소스 낭비처럼 느껴진다고 한다.
물론 프로젝트마다 정답은 없고, 코드가 많아지고 로직이 복잡해질수록 보기 어려워지는건 어쩔수 없는 문제라고 생각한다. 이 책을 읽으며 느낀건 클래스에 많이 넣느냐, 잘게 나누냐의 차이보다도 그 클래스의 단위가 역할대로 잘 나뉘어져 있느냐가 중요하다는 생각이 든다.
'BOOK Review' 카테고리의 다른 글
[스프링입문을위한 자바 객체지향의 원리와 이해] 1장 ~ 2장 (1) | 2024.09.11 |
---|---|
[클린코드] Final Review (0) | 2024.07.11 |
[클린코드] TIL - 9장 단위 테스트 (1) | 2024.07.05 |
[클린코드] TIL - 7장 오류 처리 (0) | 2024.07.02 |
[클린코드] TIL - 6장 객체와 자료 구조 (0) | 2024.06.30 |