> For the complete documentation index, see [llms.txt](https://real-dev.gitbook.io/real-library/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://real-dev.gitbook.io/real-library/clean-code/readme/10..md).

# 10. 클래스

#### 클래스는 작아야 한다.

* `클래스가 충분히 작다.` 의 기준은 해당 클래스가 가지고 있는 책임이 얼마나 다양하냐에 따라 다르다.
* 클래스의 이름은 해당 클래스의 책임을 기술해야 한다. 작명은 클래스 크기를 줄이는 첫 번째 관문이다.
* 간결한 이름이 떠오르지 않으면 대부분 해당 클래스가 너무 커서 그렇다.
* 클래스에 대한 설명은 if, and , or, but을 사용하지 않고 25자 안에서 끝나야 한다. 그만큼 작은 책임을 가지고 있어야 한다.

<br>

#### 단일 책임 원칙

* 클래스나 모듈을 변경할 이유가 하나. 딱 하나뿐이어야 한다는 원칙이다. 즉, 하나의 책임만을 지고 있어야 한다는 뜻
* SRP는 객체 지향 설계에서 아주 중요한 개념 중 하나지만, 또 엄청 많이 무시되는 개념이기도 하다. 왜냐면 SRP를 지키지 않아도 코드는 돌아가니까…!
* 하지만 프로젝트의 규모가 커질수록 하나의 컴포넌트가 너무 많은 역할을 수행하게되면, 적절한 코드를 찾는데 한 세월이 걸리게된다. 커다란 박스 하나에 모든 도구를 전부 쑤셔박는 것보다, 되도록이면 작은 서랍 여러개에 도구를 분리해서 담는게 좋다.
* 응집도: 클래스의 응집도를 높이려면 인스턴스 변수의 수가 적고, 메서드가 클래스 인스턴스 변수를 더 많이 사용하도록 변경해야 한다. 모든 인스턴스 변수를 메서드마다 사용하는 클래스가 가장 응집도 높은 클래스이다.
  * 실무 개념으로 생각해보면 하나의 서비스 클래스에 5\~6개의 레파지토리 변수가 참조되곤 하는데 그 중 일부는 1,2개의 메서드에서만 참조되고 다른 메서드에선 참조되지 않는 경우가 많다. 이런 경우 클래스의 응집도가 상대적으로 낮은 신호이므로, 별도의 클래스 분리가 필요할 수 있다.
* 결합도: 각 시스템 요소가 다른 요소부터 그리고 변경으로부터 잘 격리되어 있다는 의미이다. 특정 API가 외부 API를 직접 참조하고 있는 구조라면 결합도가 높지만, 외부 API를 호출하는 Wrapper Class를 참조하고 있다면 결합도가 상대적으로 낮은 셈이다. (다형성을 이용해 fake Client를 생성하여 테스트하기도 쉽다.)
* OCP: Open-Close-principle의 약자로, 확장에는 열려있고 변경에는 닫히 구조를 의미한다. 예를 들어 Sql이라는 클래스 안에 쿼리 관련 메소드를 죄다 때려박으면 확장이 빡센 상태로 구현된다. 지원하지 않던 update 쿼리를 지원하기 위해선 다른 메서드에 영향이 없는지 일일히 검사해야할 수 있다. 반면 Sql 클래스를 인터페이스로 선언하고, 다른 클래스들이 상속받아 구현체로 생성하면 Update 클래스를 생성할 때 기존의 클래스들에 미칠 영향을 최소화할 수 있다는 점에서 확장에 열린 구조인 것. 반대로 수정에는 닫힌 구조라는게, Update 클래스에 뭘 추가하려고 해도 Sql 인터페이스에 구현되지 않은 상태라 수정이 어려운 상태가 된다. 이것이 OCP
*

<br>