Ch10.md

Ch 10. Classes

생각 공유

@ChanhuiSeok

변경이 쉽고, 결합도가 낮고, 클래스는 크기가 작아야 하고,...! SRP라는 용어를 새롭게 접했고, 기존의 OCP 등과 연관된 내용을 확인할 수 있었다.

• 클래스 체계

  • 가장 먼저 변수 목록 → 정적 혹은 공개 상수가 맨 처음 나옴 → 그 다음 private 변수 → 이어서 비공개 인스턴스 변수 → 변수 목록 다음부터는 공개 함수 → 비공개 함수 → … (신문 기사처럼 읽힌다.)

• 비공개 상태를 유지할 온갖 방법을 강구한다. 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다.

• 클래스의 크기는 작아야 한다. 책에서는 엄청 강조하고 있다.

  • 함수의 크기는 물리적인 행 수로 크기를 측정했지만, 클래스는 맡은 책임으로 크기를 측정한다.
  • 클래스 이름은 해당 클래스 책임을 기술해야 한다.

• 단일 책임 원칙(SRP) : 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다. → 클래스는 딱 한 가지 책임, 한 가지 일만 수행하라는 말이다.

  • 큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다!

• 응집도 → 결합도와 구분해서 알면 좋겠다. (참고 : https://madplay.github.io/post/coupling-and-cohesion-in-software-engineering)

  • 클래스는 인스턴스 변수 수가 작아야 한다.
  • 몇몇 함수만 사용하는 인스턴스 변수가 늘어나면 안 된다. → 이 때, 몇몇 함수가 몇몇 변수만 사용한다면 이들을 독자적인 클래스로 분리한다! 클래스가 응집력을 잃는다면 쪼갠다.

• 변경하기 쉬운 클래스 → 어떤 변경을 할 때 마다 클래스에 손을 대야 한다면? 클래스에 손을 대면 다른 코드를 망가뜨릴 잠정적인 위험이 존재한다. 클래스를 논리적으로 잘 분리해서 기존 클래스를 변경할 필요가 없도록 만드는 것이 중요하다. ✏️ 여기서 말하는 변경하기 쉬운 클래스란 이러한 의미라고 생각한다. OCP와도 연결이 되는 개념이다.

• 변경으로부터 격리 ✏️ 여기서 결합도 이야기와, 클래스 추상화에 대해 언급하고 있다. 테스트가 가능할 정도로 시스템의 결합도를 낮춰야 유연성과 재사용성이 더욱 높아질 것이다. 결합도가 낮다는 소리는, 각 요소가 다른 요소와 변경으로부터 잘 격리되었음을 의미한다.

---

@jjangsungwon

클래스는 작아야 한다.

• 클래스를 만들 때 첫 번째 규칙은 크기다. 클래스는 작아야 한다. 두 번째 규칙도 크기다. 더 작아야 한다. (크기를 아주 강요함)
• 클래스의 크기는 맡은 책임으로 측정한다. (함수는 행수로 파악)
• 응집도와 관련, 클래스는 인스턴스 변수 수가 작아야 한다.

변경하기 쉬운 클래스

• OCP, SRP 개념과 연결하는게 흥미로웠음.
• 상세한 구현에 의존하는 코드는 테스트가 어렵다.

---

@qrlagusdn

클래스 체계

변수 목록

• static public var
• private var
• private instance var
• public
  • 공개 변수가 필요한 경우는 거의 없음
• function

클래스는 작아야함!

• 첫째 규칙도 작은 크기이고, 두번째 규칙도 작은 크기이다.
  • 어느정도?
    • → 단일 책임 원칙
  • 클래스 설명은 if, and, or, but 없이 25자 내외로 가능해야함.

SRP (Single Responsibility Principle)

• 클래스나 모듈을 변경할 이유가 하나이어야 함.
• 객체 지향에서 중요한 개념!
• 우리는 일반적으로 돌아가는 일에 집중을 하고, 다음 단계인 “깨끗하고 체계적인 소프트웨어" 라는 관심사로 전환하지 않음. ㅜㅜ
  • 즉, 개발 이후 리팩토링을 거쳐야만 한다!

클래스는 큰 몇 개가 아니라 작은 클래스 여럿으로 이루어진 시스템이 더 바람직함

• 작은 클래슨느 각자 맡은 책임이 하나이며, 변경할 이유 또한 하나이어야 한다.
• 다른 작은 클래스와 협력해서 시스템에 필요한 동작을 수행함.

응집도 (cohesion)

• 인스턴스 변수 수가 작아야함.
• 메서드가 인스턴스 변수를 많이 사용할 수록 응집도가 높음
• → 클래스에 속한 메서드와 변수가 서로 의존하면서 논리적인 단위로 묶인다는 의미
• 만약 몇몇 메서드만이 사용하는 인스턴스 변수가 많이지면 클래스를 쪼개야함!

변경하기 쉬운 클래스

• 대다수 시스템은 지속적인 변경이 불가피함.
• 따라서 SRP 따르는 깨끗한 시스템이 필요함
• OCP 도 지원하도록
  • 확장에 개방적이고, 수정에 폐쇄적이어야 한다는 원칙
• 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조!

DIP 의존성 역전 원칙

• 변화하기 쉬운 것 또는 자주 변화하는 것에 의존하기 보다는, 변화하기 어렵고 거의 변화가 없는 것에 의존해라!!
• → 결합도를 최소로 줄이면 DIP를 따르는 클래스가 나옴
  • 추상화에 의존해라!
  • → 추상 클래스는 테스트가 쉬움

---

회의록

• 폴더 관리

  • 프로젝트 루트 경로에 회의록 폴더(summary) 라고 만들고, 그 밑에 주마다 논의했던 내용을 작성해서 올린다. (서로 공유한 내용, 회의록 포함)
  • repo에 내용을 올릴 때는 main에 바로 push 한다. (따로 branch, PR 관리 X)

• issue 탭 사용

  • 구글밋 전에 한 주동안 스터디했던 장을 개인적으로 간단하게 정리해서 issue 탭에 올린다. (공유하고 싶은 내용이나 자료를 포함해도 괜찮다)
  • issue 탭에 올릴 때 타이틀은 [Ch1] 챕터 제목 이름 의 형태로 올린다.
  • 구글밋에서 각자 생각을 공유할 때 issue 탭에 작성한 것을 참고용으로 활용하면 좋겠다.