10. 클래스

깨끗한 클래스

클래스 체계#

클래스 순서#

추상화 단계가 순차적으로 이루어져 읽기 쉽도록

  1. static public 상수
  2. static private 인스턴스
  3. private 인스턴스
  4. public method
  5. private method는 호출한 public method 바로 밑에

캡슐화#

  • 캡슐화를 풀어주는 정책은 다른 해결책이 없을때만..

클래스는 작아야 함#

  • 얼마나?
    • 맡은 책임이 하나만 (SRP, 단일 책임의 원칙)
  • 작은 클래스 여럿으로 이뤄진 시스템이 바람직
    • 변경 시, 알아야할 내용을 줄일 수 있음

작게 구현하는 법#

  • SRP, 책임은 하나만
  • 클래스 이름에 책임이 담기도록 구성
    • 이름이 클래스 크기를 줄이는 첫번째 관문

응집도#

  • 응집도를 를 높게 유지
    • 인스턴스 변수 수를 작게 유지
    • 메서드는 클래스 인스턴스 변수를 하나 이상 사용하기
  • 함수를 작게, 매개변수 목록을 적게를 따르다 보면 특정 메서드만 사용하는 특정 필드들이 생겨남
    • 이는 클래스를 쪼개야하는 신호
  • 큰 함수를 작게 쪼개다 보면 응집력을 잃음
    • 응집력이 없어져 가는 것을 본다면 해당 클래스를 나눔
    • 이런 행위를 반복하면서 프로그램에 체계가 잡혀나가게 됨

변경하기 쉬운 클래스#

  • 클래스 일부 메서드에서만 사용되는 private는 코드를 개선할 냄새를 풍김
    • (밥 아저씨의 경험 공유)
  • 새기능을 수정하거 기존 기능을 변경할 때 건드리는 코드가 최소인 시스템 구조가 바람직!
    • OCP, 개방 폐쇄 원칙 을 지키면 가능

변경으로부터 격리#

  • abstract 클래스, interface를 많이 활용함
  • 테스트 가능할 정도로 결합도를 낮추면 유연성과 재사용성도 높아짐
  • 결합도를 줄이다 보면 DIP (Dependency Inversion Principle) 을 지키게 됨
    • 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다는 원칙
Edit this page
Last updated on