클린코드 TIL (10장)

TIL (Today I Learned) 날짜

2022.05. 11(수)

오늘 읽은 범위

10장 클래스 

책에서 기억하고 싶은 내용을 써보세요.

• 소프트웨어를 그저 동작하게 만들 뿐만 아니라 깨끗하게 만들어야 한다. 
• 좋은 클래스를 만들기 위한 질문 2가지
  • 클래스의 크기가 충분히 작은가 
    • 함수와 마찬가지로 클래스도 '작게' 설계하는 게 기본 규칙이다. 
    • 간결한 이름이 떠오르지 않는다? -> 클래스 크기가 너무 크다는 뜻!
  • 책임이 적당한가
    
    • 모호한 이름이 떠오른다? -> 클래스 책임이 많다는 뜻! 
• 기억해야 할 클래스 규칙 
  • 캡슐화 유지하기 
    • 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다.
  • 단일 책임원칙(SRP : Single Responsibility Principle) 
    • 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다. (맡은 책임 하나)
    • 변경할 이유를 파악하려 애쓰다 보면 코드를 추상화하기 쉬워진다. 
    • 무엇이 어디에 있는지 파악하기가 쉬워진다. 
    • 당장 알 필요가 없는 사실들은 공개하지 않는다. 
  • 응집도가 낮아야 한다.
    • 응집도(결합도)가 높다는 건 메서드와 변수가 서로 뒤엉켜 의존하고 있다는 의미
    • 크기가 커지는 문제를 막기 위해서 작은 단위로 계속 쪼개야 한다. 그러다 보면 체계가 잡히고 구조가 투명해진다. 
    • 각 시스템 요소가 다른 요소의 변경으로부터 잘 격리되어 있는 의미 
  • 변경하기 쉬워야 한다. 
    • 깨끗한 시스템은 변경에 수반하는 위험이 적다.
    • 하나의 수정이 다른 부분을 망가뜨릴 위험이 없다. 
    • OCP (Open-Closed Principle)
      • 확장에 개방적이고 수정에 폐쇄적이다
      • 새 기능을 추가하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템이 바람직하다.
  • DDP (Dependency Inversion Principle)
    • 상세한 구현이 아니라 추상화에 의존해야 한다.
    • 추상화 예시 : 인터페이스
• 요구사항은 늘 변하고 코드는 함께 바뀌어야 한다. 
• 리팩토링한 코드는 길이가 길다?
  • 더 길고 서술적인 변수 이름을 사용하기 때문
  • 코드에 주석을 추가하는 수단으로 함수 선언과 클래스 선언을 활용하기 때문
  • 가독성을 높이고자 공백을 추가하고 형식을 맞추기 때문

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

• 책 초반에서 부터 계속해서 말해오는 클린 코드의 원칙(단일 책임원칙, 확장성, 가독성 등)이 클래스에 어떻게 적용되는지 확인할 수 있었다. 읽기 좋은 코드란 단순한 코드의 가독성을 넘어 좋은 설계가 무엇인지에 대해 고민해야 한다는 걸 배웠다.