![](https://velog.velcdn.com/images/chappse6/post/2cbc22bf-a67b-410e-bb13-1132e5565ead/image.png)
오늘 TIL 3줄 요약
- 클래스는 작아야 한다!
- 클래스는 인스턴스 변수 수가 작아야 한다.
- 클래스는 변경이 쉬워야 한다.
TIL (Today I Learned) 날짜
2022.05.10 ~
2022.05.11
오늘 읽은 범위
10장 클래스
책에서 기억하고 싶은 내용을 써보세요.
클래스를 설계할 때도, 함수와 마찬가지로, '작게'가 기본 규칙
- 함수의 크기 : 물리적인 행의 수로 측정
- 클래스의 크기 : 클래스가 맡은 책임을 셈
클래스 이름은 해당 클래스 책임을 기술해야 한다.
- 간결한 이름이 떠오르지 않는다면 필경 클래스 크기가 너무 커서
- 클래스 이름이 모호하다면 필경 클래스 책임이 너무 많아서다
- 클래스 이름에 Processor, Manager, Super 등과 같이 모호한 단어가 있다면 클래스에다 여러 책임을 떠안겼다는 증거다.
단일 책임 원칙(Single Responsibility Principle, SRP)
- 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다.
- SRP는 '책임'이라는 개념을 정의하며 적절한 클래스 크기를 제시한다.
- 클래스는 책임, 즉 변경할 이유가 하나여야 한다는 의미다
=> 책임, 즉 변경할 이유를 파악하려 애쓰다 보면 코드를 추상화하기도 쉬워진다.
소프트웨어를 돌아가게 만드는 활동과 소프트웨어를 깨끗하게 만드는 활동은 완전히 별개다
'깨끗하고 체계적인 소프트웨어'보다 '돌아가는 소프트웨어'에 초첨을 맞추는 이유 두가지
- 프로그램으로 되돌아가 만능 클래스를 단일 책임 클래스 여럿으로 분리하는 대신 다음 문제로 넘어가버린다.
- 많은 개발자는 자잘한 단일 책임 클래스가 많아지면 큰 그림을 이해하기 어려워진다고 우려한다.
"도구 상자를 어떻게 관리하고 싶은가? 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 넣고 싶은가? 아니면 큰 서랍 몇 개를 두고 모두를 던져 넣고 싶은가?"
큰 클래스 몇개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다
작은 클래스란?
- 각자 맡은 책임이 하나며,
- 변경할 이유가 하나며,
- 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.
응집도가 높다는 말은 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미
Open-Closed Principle(OCP)
- OCP란 클래스는 확장에 개발적이고 수정에 폐쇄적이어야 한다는 원칙이다.
새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다.
구체적인(concrete) 클래스는 상세한 구현(코드)을 포함하며 추상(abstract) 클래스는 개념만 포함
상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다
=> 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리한다.
Dependency Inversion Principle(DIP)
- DIP는 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다는 원칙이다.
결합도가 낮다는 소리는 각 시스템 요소가 다른 요소로부터 그리고 변경으로부터 잘 격리되어 있다는 의미다.
시스템 요소가 서로 잘 격리되어 있으면 각 요소를 이해하기도 더 쉬워진다.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
오늘은 책을 한 번 읽고 완벽하게 이해가 되지 않는다고 느꼈는데 wowyowowyo님의 TIL 를 읽고 도움이 많이 되었다. 깨끗한 클래스를 작성하기 위해서는 생각보다 많은 부분을 신경 써야한다는 것을 다시금 느끼게 되었다. 책을 읽으면서 가장 핵심은 "클래스는 작아야 한다!"라고 생각했다.
오늘 읽은 다른사람의 TIL
wowyowowyo님의 TIL