개발자 99% 커뮤니티에서 수다 떨어요!
오늘 TIL 3줄 요약
클래스는 작을 수록 좋다
하나의 클래스는 하나의 책임만!
응집력 있는 클래스를 만들어라
TIL (Today I Learned) 날짜
2022.05.10
오늘 읽은 범위
10장 클래스
책에서 기억하고 싶은 내용을 써보세요.
<클래스 체계>
변수목록 : 정적static 공개 public 상수 > 정적 비공개 private 변수 > 비공개 인스턴스 변수
변수목록 다음에는 공개함수가 나오고 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 즉 추상화 단계가 순차적으로 내려감
<클래스는 작아야 한다!>
클래스를 설계할 때도, 함수와 마찬가지고 '작게'가 기본 규칙
클래스 이름은 해당 클래스 책임을 기술해야 한다. (실제로 작명은 클래스 크기를 줄이는 첫번째 관문)
클래스 이름이 모호하다면 클래스 책임이 너무 많아서다.
[단일 책임 원칙 (SRP : Single Responsibility Principle) ]
단일 책임 원칙 : 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다는 원칙
규모가 어느 수준에 이르는 시스템은 논리가 많고도 복잡하다. 이런 복잡성을 다루려면 체계적인 정리가 필수다.
큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다. 작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.
[응집도 Cohesion]
클래스는 인스턴스 변수 수가 작아야 한다. 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다.
일반적으로 메서드가 변수를 더 많이 사용할수록 베서드와 클래스는 응집도가 더 높다. 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높다.
우리는 응집도가 높은 클래스를 선호하는데, 응집도가 높다는 말은 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미기 때문.
[응집도를 유지하면 작은 클래스 여럿이 나온다]
클래스가 응집력을 잃는다면 쪼개라
<변경하기 쉬운 클래스>
어떤 변경이든 클래스에 손대면 다른 코드를 망가뜨릴 잠정적인 위험이 존재한다. 그래서 테스트도 다시 해야한다.
새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지 않는다.
[변경으로부터 격리]
결합도가 낮다는 소리는 각 시스템 요소가 다른 요소로부터 그리고 변경으로부터 잘 격리되어 있다는 의미다. 시스템 요소가 서로 잘 격리되어 있으면 각 요소를 이해하기도 쉬워진다.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
아직 클래스를 많이 사용해보지 않아서 어려운 내용이었지만 함수와 마찬가지로 작고 간결하게, 기능은 하나만! 이 계속 강조되는 것 같다.