[10장] 클래스

[aronalee]

요약

• 함수의 수는 클래스의 책임을 의미한다
• 클래스의 이름은 책임을 내포해야 한다
• Processor, Manager, Super 같은 정보는 책임을 떠넘겼다는 증거다
• 단일 책임 원칙: 모듈을 변경해야하는 이유는 '책임'이란 이유 뿐이다
• 메소드가 변수를 많이 사용할 수록 메소드와 클래스는 응집도가 높다는 의미다
• 리팩토링 과정에서 클래스가 응집력을 읽는다면 여러개의 클래스로 쪼갤 수 있다

---

생각

항상 말하고 다녔지만 지키기에 어려웠던 책임이라는 내용에 대해 학습할 수 있었다. 하나의 책임을 가져야 한다는 것은 알고 있었으나 '어떻게 해야 하나의 책임을 갖지' 라는 것에 의문이 있었기 때문이다. 그렇기에 어떻게 책임을 측정할 수 있을까에 대한 내용을 고민하고 있었다. 이 챕터에서 이러한 고민을 풀 수 있어서 '저자는 책임을 이런 식으로 생각하는구나'를 알 수 있었다.

[chj990707]

• 클래스를 작게 유지하라
• 캡슐화: 변수와 내부함수는 최대한 숨겨야 한다
• 단일 책임 원칙: 변경해야 할 이유가 곧 책임이다
• 응집도: 인스턴스 변수 수를 줄여야 한다
• 클래스는 변경하기 쉬워야 한다

생각

클래스를 변경해야 할 이유가 곧 책임이므로 변경해야 할 이유를 하나로 유지해야 한다는 저자의 말이 인상깊었다. 매번 코드를 짤 때마다 이 클래스엔 이 기능이 필요하지 않을까 하는 이유로 코드가 쉽게 난잡해지고는 했기 때문에 중요한 내용이라고 생각한다.

[Roddyd94]

개념

• 캡슐화 - 구현의 일부를 내부에 감추어 은닉하는 것. 변수나 유틸리티 함수를 숨겨서 캡슐화
• 응집도 - 모듈의 내부 구성 요소가 얼마나 연관되는가. 메서드가 클래스 인스턴스 변수를 많이 사용할 수록 높다.
• SRP - 클래스나 모듈을 변경할 이유가 하나여야 한다.
• OCP -
• DIP

방법

• 캡슐화를 푸는 것은 최후에 결정하라
• 클래스는 (책임을 기준으로) 작게 만들라
• 응집도가 높은 변수와 메서드를 새로운 클래스로 분리
• 클래스를 추상 클래스로 만들고 파생 클래스에 책임 분리
• 인터페이스와 추상클래스를 사용하여 구현이 미치는 영향 분리

생각

클래스를 책임에 따라 나눈다는 것과 객체지향의 설계 원칙이 깊게 연관되어 있다는 것을 알 수 있었다. 클래스 이름에 Manager, Processor, Super 등의 단어가 들어가면 다수의 책임이 있다는 부분에서 뜨끔했다.