오늘 TIL 3줄 요약

• 클래스는 작을 수록 좋다

• 하나의 클래스는 하나의 책임만!

• 응집력 있는 클래스를 만들어라

TIL (Today I Learned) 날짜

2022.05.10

오늘 읽은 범위

10장 클래스

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

<클래스 체계>

• 변수목록 : 정적static 공개 public 상수 > 정적 비공개 private 변수 > 비공개 인스턴스 변수

• 변수목록 다음에는 공개함수가 나오고 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 즉 추상화 단계가 순차적으로 내려감

<클래스는 작아야 한다!>

• 클래스를 설계할 때도, 함수와 마찬가지고 '작게'가 기본 규칙

• 클래스 이름은 해당 클래스 책임을 기술해야 한다. (실제로 작명은 클래스 크기를 줄이는 첫번째 관문)

• 클래스 이름이 모호하다면 클래스 책임이 너무 많아서다.

  ---

  [단일 책임 원칙 (SRP : Single Responsibility Principle) ]

• 단일 책임 원칙 : 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다는 원칙

• 규모가 어느 수준에 이르는 시스템은 논리가 많고도 복잡하다. 이런 복잡성을 다루려면 체계적인 정리가 필수다.

• 큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다. 작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.

  ---

  [응집도 Cohesion]

• 클래스는 인스턴스 변수 수가 작아야 한다. 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다.

• 일반적으로 메서드가 변수를 더 많이 사용할수록 베서드와 클래스는 응집도가 더 높다. 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높다.

• 우리는 응집도가 높은 클래스를 선호하는데, 응집도가 높다는 말은 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미기 때문.

  ---

  [응집도를 유지하면 작은 클래스 여럿이 나온다]

• 클래스가 응집력을 잃는다면 쪼개라

<변경하기 쉬운 클래스>

• 어떤 변경이든 클래스에 손대면 다른 코드를 망가뜨릴 잠정적인 위험이 존재한다. 그래서 테스트도 다시 해야한다.

• 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지 않는다.

  ---

  [변경으로부터 격리]

• 결합도가 낮다는 소리는 각 시스템 요소가 다른 요소로부터 그리고 변경으로부터 잘 격리되어 있다는 의미다. 시스템 요소가 서로 잘 격리되어 있으면 각 요소를 이해하기도 쉬워진다.

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

아직 클래스를 많이 사용해보지 않아서 어려운 내용이었지만 함수와 마찬가지로 작고 간결하게, 기능은 하나만! 이 계속 강조되는 것 같다.