[클린 코드] 10장 - 클래스

 

이번 챕터는 자바 관례에 대한 글이 될 것 같아요. Java로 개발을 할 때에는 아래 규칙들을 지키려고 노력을 하고, Swift로 iOS 개발을 할 때에는 보다 깔끔한 코드를 위해 참고하는 정도로 이해할 생각이에요.

 

1. 클래스 체계

가장 먼저 변수 목록이 나와요.

public static 변수가 먼저 나오고, 그 후에 private static변수가 나와요. 그 후에 private 인스턴스 변수가 나와요. 순서로 보면 public ➡️ private, static ➡️ instance 변수 순서로 나와요.

변수 목록 다음에는 공개 함수가 나와요. 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣어요. 즉, 추상화 단계가 순차적으로 내려가요.

 

class SomeClass {
    static let someStatic = 10
    static private let somePrivateStatic = 20
    private let someInstance = 30
    
    func somePublicFunc() {
        somePrivateFunc()
    }
    
    private func somePrivateFunc() {
        // ...
    }
}

 

나의 생각: 일반 클래스와 다르게 ViewController에서 변수들을 만들 때 고민을 많이 했어요. View 인스턴스를 생성할 경우가 많기 때문에 일반 변수와 구분이 되기 때문이에요. 설계 구조에 따라 다를 수 있지만, 일반적으로 저는 로컬에서 사용할 Enum이나 Dependency가 있을 경우 가장 최상단에 배치시키고, 그 이후 View에 관련된 변수를 주석으로 구분, 그 후에 일반 변수들을 위의 규칙에 따라 주석으로 따로 구분 지어 놓고 그 이후에 메서드를 넣는 구조로 작업하는 컨벤션으로 정했어요.

 

2. 캡슐화

변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없어요. 우리에게 테스트는 매우 중요하기 때문에 같은 패키지 안에서 테스트 코드가 함수를 호출하거나 변수를 사용해야 한다면 그 함수나 변수를 공개하기도 해요. 하지만 그 전에 비공개 상태로 유지할 방법을 강구하는 게 좋아요. 캡슐화를 풀어주는 결정은 언제나 최후의 수단이에요.

 

3. 클래스는 작아야 한다!

클래스를 만들 때 첫 번째 규칙은 크기에요. 클래스는 작아야 해요. 그럼 생기는 의문은 "얼마나 작아야 하는가?"에요. 함수는 물리적인 행 수로 크기를 측정했지만 클래스는 다른 척도를 사용해요. 클래스가 맡은 책임을 기준으로 세요. 메서드의 개수가 적더라도 책임이 많다면 문제가 있어요.

클래스 이름은 해당 클래스 책임을 기술해야 해요. 실제로 작명은 클래스 크기를 줄이는 첫 번째 관문이에요. 간결한 이름이 떠오르지 않는다면 클래스의 크기가 너무 커서 그럴 가능성이 높아요. 예를 들어, 클래스 이름에 Processor, Manager, Super 등과 같이 모호한 단어가 있다면 클래스에다 여러 책임을 떠 안겼다는 증거예요.

또한 클래스 설명은 "if", "and", "or", "but"을 사용하지 않고 25 단어 내외로 가능해야 해요. "이 객체는 ~~를 하며 ~~~를 해요"라는 설명은 "하며"가 들어가는 순간 너무 많은 책임을 가진 객체라는 증거가 돼요.

 

나의 생각: Manager라는 단어가 나와서 찔렸어요.. ㅋㅋ 현업에서 작업할 때 프로젝트에 Manager가 매우 많이 있었고, 저 역시도 Manager를 구현한 경험이 여러 번 있었어요. 개인적으로 책의 내용과 다르게 Manager라는 이름의 클래스가 있다고 해서 그 클래스가 과대하게 설계된 클래스라고 생각하지는 않아요. 우선 이상과 현실의 차이가 있고, 더 중요하게는 매니저를 어떻게 정의하느냐에 따라 다르다고 생각해요. 예를 들어, 여러 ViewController에서 특정 데이터의 cache hit를 하고, 없을 경우 서버 호출을 통해 받아오는 작업을 할 때에, 각 작업이 일어나는 객체에서 직접 동작시키기보다 이 작업을 하는 하나의 객체를 따로 만들어 이 객체한테 요청하는 구조가 더 적합하다고 판단했어요. 그리고 이러한 작업을 하는 객체의 이름에 Manager가 들어간다고 해서 이 객체가 너무 많은 일을 한다고 생각하지는 않아요. 다만, 관리하는 객체라는 이름이 붙은 만큼 그 이름하에서 묶일 수 있는 작업만 있어야 하고, 관리라는 이름 하에 너무 많은 작업을 정의하지 않는 게 중요하다고 생각해요. Manager라는 이름으로 객체를 만드는 게 문제가 아니라 '관리'라는 단어에 들어갈 작업을 적절히 정의하는 게 중요하다고 판단했어요.

 

4. 단일 책임 원칙(SRP: Single Responsibility Principle)

단일 책임 원칙은 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다는 원칙이에요. 책임, 즉 변경할 이유를 파악하려 애쓰다 보면 코드를 추상화하기도 쉬워져요. 

큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직해요. 작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행해요.

 

나의 생각: 이 글을 읽으며 제가 있었던 팀의 코드에 대해 생각해봤어요. 그 당시는 최선이라고 생각했는데 더 분리할 여지가 있지 않았을까? 하는 생각이 스쳐갔어요. 최선은 코드를 작성할 때부터 완벽한 설계를 하는 것이지만, 현실적으로 빠른 작업을 요하는 팀에서는 정말 어려운 일이라고 생각돼요. 다만 속도만을 추구해서 작업을 하는 것은 결국 잠재적으로 추후 리팩터링 작업을 늘려가는 것이기 때문에 개인적인 작업을 하더라도 설계할 때부터 이 부분을 좀 더 신경 써서 하면 좋을 것 같아요. 

 

5. 응집도

클래스는 인스턴스 변수 수가 적어야 해요. 각 클래스 메서드는 클래스 인스턴 변수를 하나 이상 사용해야 해요. 일반적으로 메서드가 변수를 더 많이 사용할수록 메서드와 클래스는 응집도가 더 높아요. 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높아요. 

이런 응집도가 가장 높은 클래스는 가능하지도 바람직하지도 않아요. 하지만 우리는 응집도가 높은 클래스를 선호해요. 응집도가 높다는 말은 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미기 때문이에요.

응집도를 유지하면 작은 클래스 여럿이 나와요.

 

6. 변경하기 쉬운 클래스

깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춰요. 경험에 의하면 클래스 일부에서만 사용되는 비공개 메서드는 코드를 개선할 잠재적인 여지를 시사해요. 하지만 실제로 개선에 뛰어드는 계기는 시스템이 변해서라야 해요.

새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직해요. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않아요.

 

 

 

 

 

클린코드(Clean Code) by Robert.C.Martin