본문 바로가기

Book/Clean Code

[클린 코드] Assignment #12: TIL - 10장. 클래스

728x90

 

📢 DAY 17 ~ 18
🏷️ 오늘 읽은 범위: 10장. 클래스

🖊️ 짧은 내용 요약

🧩 기본 클래스 구조

클래스는 기본적으로 캡슐화를 하고, 깨끗하게 작성한 클래스 내부의 구조는 다음과 같다.

정적 공개 상수
정적 비공개 변수
비공개 인스턴스

공개 합수
비공개 함수

 

🌟 깨끗한 클래스를 만드는 규칙

  • 작게 만든다.
    클래스가 하나의 책임만 가지면, 작은 것으로 판단한다. 클래스의 이름은 해당 클래스의 책임을 기술하기 때문에, 클래스가 하나의 책임만 지고 있는지를 판단하려면 클래스의 이름을 살펴본다. 클래스 명에 모호한 단어나 if, and, or, but과 같은 단어를 사용하지 않고 25자 이내로 작성했는지 확인한다.
  • 클래스의 응집력을 적절히 유지한다.
    클래스의 응집력을 유지하려면, 클래스의 인스턴스 변수 수가 작아야 하고, 클래스의 메서드가 클래스의 인스턴스 변수를 하나 이상 사용해야 한다. 그렇다고 메서드가 인스턴스 변수를 너무 많이 사용하면, 메서드와 변수가 서로 너무 의존해 바람직하지 않다. 이때 클래스의 응집력을 유지하기 위해 함수를 쪼개거나, 함수들과 함수들이 사용하는 변수들을 묶어 작은 클래스로 쪼갠다.
  • 변경하기 쉽도록 구현한다.
    대다수의 시스템은 지속적인 변경이 일어나기 때문에 클래스도 변경에 유연하도록 구현해야 한다. 이때 기존 코드를 변경하지 않고 새로운 기능을 추가하거나 수정할 수 있는 구조로 구현한다. 또한, 상세한 구현에 의존하게 되는 클래스는 추상화에 의존하도록 변경한다

😀 책에서 기억하고 싶은 내용

"도수 상자를 어떻게 괸리하고 싶은가?
작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 놓고 싶은가?
아니면 큰 서랍 몇 개를 두고 모두를 던져 넣고 싶은가?" (p. 177)
더보기
하지만 작은 클래스가 많은 시스템이든 큰 클래스가 몇 개뿐인 시스템이든 돌아가는 부품은 그 수가 비슷하다. 어느 시스템이든 익힐 내용은 그 양이 비슷하다. (p. 177)
"도수 상자를 어떻게 괸리하고 싶은가? 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 놓고 싶은가? 아니면 큰 서랍 몇 개를 두고 모두를 던져 넣고 싶은가?" (p. 177)
작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유도 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다. (p. 177)

🤔 오늘 읽은 소감 & 떠오르는 생각

예제 중에 SQL 클래스를 SRP와 CP 원칙을 지키도록 리펙토링한 코드가 있다. 이때 나는 리펙토링 하기 전 SQL 클래스 코드가 더 사용하기 편해 보여서 리펙토링한 코드에 공감이 완전히 가지 않았다... 나중에 클래스에 수정이 일어날 때는 물론 리펙토링한 코드가 훨씬 잘 쓰여졌지만, 변경 전의 SQL 클래스와 같은 API 형태를 많이 봤던 것 같은데, 리펙토링된 코드는 API로 사용한다면 호출할 때 번거로움이 생길 것 같았다. 그리고 클래스가 변경에 유연하도록 추상화에 의존하게 만들라는 설명은 잘 이해가 되지 않았다. 아직은 더 많이 개발을 해보는 경험이 필요한 것 같다!

🔍 새로 알았거나 잘 이해되지 않는 내용

  • 단일 책임 원칙(Single Responsibility Principle)
    객체는 단 하나의 책임만 가져야 한다.
  • DIP(Dependency Inversion Principle)
    어떤 클래스를 참조해서 사용해야 한다면, 그 클래스 대신 그 클래스의 상위 요소를 참조한다.

📚 참고

반응형