[개발자 책읽기] 클린 코드-애자일 소프트웨어 장인 정신 (10장 클래스)

해당 글은 Robert C.Martin 클린 코드 라는 책을 읽고 학습한 내용을 정리 및 회고하는 글 입니다. 자세한 사항은 YES 24 클린 코드 - 애자일 소프트웨어 장인 정신 에서 확인해주세요.

 

클린 코드 - 애자일 소프트웨어 장인 정신 (Uncle Bob)

 

• 위키북스
• 지은이: Robert C.Martin (Uncle Bob)
• 옮긴이: 박재호, 이해영

 

---

 

이번 장에서 이야기하고자 하는 것

 

클래스 체계

• 캡슐화
  • 변수나 유틸리티 함수를 protected 로 선언한다.
  • 캡슐화를 풀어주는 것은 언제나 최후의 수단이다

 

클래스는 작아야 한다

• 클래스를 만들 때 첫 번째 규칙은 크기이다.
  • 클래스는 작아야 한다.

 

클래스의 이름은 해당 클래스의 책임을 기술해야 한다.

• 클래스 이름의 작명이야말로 클래스를 줄이는 첫번째 척도이다
• 클래스의 이름이 당장 떠오르지 않는다면 클래스가 여러 책임을 갖고 있다는 뜻이다.
• 클래스 이름에 Manager, Processor 등의 모호한 키워드가 있다면 여러 책임을 갖고 있다는 뜻이다.
• 클래스의 이름은 if, and, or, but 을 사용하지 않고 25단어 내외로 설명이 가능해야 한다

 

단일 책임 원칙

• 클래스를 변경할 이유는 단 하나 뿐이어야 한다.
• 가장 쉬운 원칙이지만 가장 지켜지지 않는 원칙이다
• 큰 클래스 몇개가 아닌 작은 클래스 여럿으로 나뉘어진 시스템이 바람직하다
• 작은 클래스는 다른 작은 클래스와 협력을 통해 필요한 동작을 수행해 나가야 한다.

 

응집도

• 클래스는 인스턴스 변수 수가 작아야 한다.
• 메서드가 변수를 더 많이 사용할 수록 응집도가 높다
• 무조건적으로 응집도가 높다고 해서 좋은 클래스는 아니다
  • 클래스가 인스턴스 변수를 많이 갖고 있다면 분리해야할 신호이다

 

변경하기 쉬운 클래스

• 시스템은 언제던 변화에 잘 대처할 수 있어야 한다.
• 변경을 하기 위해 SRP 를 잘 고려해보라
• 변경으로부터 격리
  • 객체지향에서는 구체 클래스와 추상 클래스가 존재한다.
    • 구체 클래스 : 상세한 구현
    • 추상 클래스 : 개념만 표현
  • 구현에 의존하는 클라이언트는 변경에 취약하다
  • 우리는 인터페이스와 추상을 이용해 수현에 미치는 영향을 격리해야 한다.

 

나의 해석과 회고

 

지금까지 클래스 이름에 대해서 고민해본 적이 있을까?

 

내 웹 백엔드는 Spring Layered Architecture 로부터 시작되었다.

 

널리 알려져있다 싶이 Layered Architecture 의 특성에 따라서 어쩌면 정해져있는 클래스명을 Entity 이름과 함께 사용하기만 했었다.

 

xxxService, xxxController, xxxRepository 처럼 말이다.

 

이는 결국 어떤 Entity 가 만들어지면 너무나도 자연스럽게 Entity 에 따른 Service, Controller, Repository 가 생겨났으며 그 클래스들의 책임과 역할에 대해서는 고민할 여지조차 존재하지 않았다.

 

하지만 최근 내가 속한 트레바리에서 프로젝트를 진행하며 느낀 바가 있다.

 

Spring 은 그냥 Spring 이고 만능이 아니다. 즉, Spring 은 도구이며 그에 영향을 받지 않아야 한다는 것이다.

 

해당 프로젝트에서는 웹 백엔드를 설계하고 구축하는 프로젝트였지만 Spring 에 많은 영향을 받지 않고 개발을 했었다.

 

그에 따라서 자연스럽게 Layered Architecture 이라는 생각이 멀어졌고 각각 클래스의 이름이 갖고있는 책임과 의미에 대해서 개발인생 처음으로 고민을 해봤었다.

 

만약 그 과정들을 겪지 않고 이번 챕터를 읽었더라면 아마 나는

 

xxxService, xxxController, xxxRepository 를 어떻게 더 책임감있게 이름을 짓지?! 너무 추상적인 챕터야

 

하고 넘어갔을 것이다.