TIL (Today I Learned)

2022.05.17

오늘 읽은 범위

10장. 클래스

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

• 캡슐화 (p.172)
  • 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없다.
  • 그 전에 비공개 상태를 유지할 온갖 방법을 강구한다. 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다.

• 클래스는 작아야 한다! (p.172-173)
  • 함수는 물리적인 행 수로 크기를 측정했다. 클래스는 맡은 책임을 센다.
  • 클래스 이름은 해당 클래스 책임을 기술해야 한다.
    : 간결한 이름이 떠오르지 않는다면 필경 클래스 크기가 너무 커서 그렇다. 클래스 이름이 모호하다면 필경 클래스 책임이 너무 많아서다.
  • 클래스 설명은 만일(“if”), 그리고(“and”), -(하)며(“or”), 하지만(“but”)을 사용하지 않고서 25단어 내외로 가능해야 한다.

• 단일 책임 원칙 (SRP, Single Responsibility Principle) (p.175-176)

  • 클래스는 책임, 즉 변경할 이유가 하나여야 한다.

  • 문제는 프로그램이 돌아가면 일이 끝났다고 여기는 데 있다. 프로그램으로 되돌아가 만능 클래스를 단일 책임 클래스 여럿으로 분리하는 대신 다음 문제로 넘어가버린다.

    • SPR 단점
      많은 개발자는 자잘한 단일 책임 클래스가 많아지면 큰 그림을 이해하기 어려워진다고 우려한다. 큰 그림을 이해하려면 이 클래스 저 클래스를 수없이 넘나들어야 한다고 걱정한다.

    • 그럼에도 불구하고 써야하는 이유
      규모가 어느 수준에 이르는 시스템은 논리가 많고도 복잡하다. 이런 복잡성을 다루려면 체계적인 정리가 필수다. 그래야 개발자가 무엇이 어디에 있는지 쉽게 찾는다. (변경을 가할 때) 직접 영향이 미치는 컴포넌트만 이해해도 충분함.

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

• 응집도Cohesion (p.177)
  • 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다.
  • 응집도가 높다 == 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다.
  • 몇몇 메서드만이 사용하는 인스턴스 변수가 아주 많아진다. 이는 십중팔구 새로운 클래스로 쪼개야 한다는 신호다. 응집도가 높아지도록 변수와 메서드를 적절히 분리해 새로운 클래스 두세 개로 쪼개준다.

• 변경하기 쉬운 클래스 (p.185)
  • 대다수 시스템은 지속적인 변경이 가해진다. 깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다.

---

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

🔽 몇몇 메서드만이 사용하는 인스턴스 변수가 아주 많아진다. 이는 십중팔구 새로운 클래스로 쪼개야 한다는 신호다. 응집도가 높아지도록 변수와 메서드를 적절히 분리해 새로운 클래스 두세 개로 쪼개준다.

• 응집도가 높은 것이 바람직 한 것만은 아니겠군..

• 나는 클래스 분리를 선뜻 생각하지 않는 편이라, 클래스를 쪼개는 상황을 기회가 생긴다.라고 표현 한 것이 인상적이었다.

나는 보통

• 로직 복잡도가 올라가거나,
• 코드 라인이 지나치게 길어질 때,
• 중복적으로 사용되는 부분이 많아 공통으로 분리할 때
• ..
  같은 경우에 꽤 고민 하다가 정 불가피하게 해야된다면 클래스로 분리했다.

그래서 보통 로직이 골치아플때 많이 겪은 상황이라 이걸 긍정적으로 볼수도 있겠구나 싶었다. 아무래도 나는 개발 표준이라는 큰 틀을 벗어나고 싶지 않아 했던 것 같다. (클래스 분리를 한 코드에 개발표준 내에서 처리하라는 피드백을 받은 이후 부터 였던 듯 하다.)
클래스 분리가 개발 표준을 크게 해치는 것일까..? 오히려 가독성을 높여줘 코드 파악에는 더 도움이 될 수도 있을텐데 싶다.
혼자서 개발하면 상관 없겠지만, 여러명이서 개발 할 때는 내 판단하에 분리를 할 수 없으니 서로 합의하에 이루어 된다고 생각한다.. 그러면 코드 작성 전이나 커밋 전에 협의 해서 정하는 걸까?

---

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• 최상위 GUI 윈도의 스윙 표현
  • JFrame
  참고 | 자바(Java)의 기초 박살내기 - Java GUI②
  
• 스윙 코드
• 버전 번호

(* 클래스 설계 원칙)

• OCP (Open-Closed Principle) (p.188)
  : 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다는 원칙.
• DIP (Dependency Inversion Principle)
  • 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다는 원칙.