cleancode #10, 클래스

목표: 깨끗한 클래스 만들기

 

Class should be small

클래스 체계 / encapsulation

• 클래스 항목의 순서

class

• 캡슐화
  • public으로 선언된 변수는 거의 없음
  • 변수와 유틸리티 함수는 가능한 공개하지 않기
  • 테스트를 위해 protected/default로 선언하는 경우는 있음

 

클래스는 작아야 한다, 최소의 책임!

• 클래스의 역할을 and, if, or, but을 사용하지 않고 25 단어 내외로 설명할 수 있어야

단일 책임 원칙(Single Responsibility Principle; SRP)

• 변경해야 하는 이유가 하나뿐이어야 한다. -> 수정 이유가 같은 것들을 묶는다. -> 유지보수를 쉽게!
• 작은 클래스 여러 개가 큰 클래스 하나보다 낫다.
• 다른 작은 클래스와 협력하여 동작하도록

 

응집도(cohesion of class)

• 클래스는 인스턴스 변수의 수가 적어야 한다.
• 메서드가 인스턴스 변수를 더 많이 사용할수록 메서드와 클래스는 응집도가 높다.
• 응집력을 잃는다면 클래스를 분리하라(응집도를 유지하면 작은 클래스가 여러 개 나온다).
• 함수를 작게, 매개변수 목록을 짧게

 

쪼개라

변경하기 쉬운 클래스(가 되도록 쪼개라)	변경으로부터 격리(시키기 위해 쪼개라)
새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소가 되게끔	다른 기능은 보존
특정 함수에서만 사용하는 private 메서드가 있다면 쪼갤 신호	결합도를 낮춰 테스트 코드 작성을 용이하게
한 클래스에 너무 많은 책임이 있지 않도록	변경이 심하거나 외부에 영향을 받는 로직은 추상적인 개념을 분리해 인터페이스(추상클래스)로 분리한다음 테스트 클래스를 만들어서 테스트

 

쪼개야 할 클래스의 예시로 clean code의 저자는 아래를 보여준다.

before

 

after

Sql은 추상 클래스로 분리하고 각각의 책임들을 클래스로 분리했다. 이로써 얻을 수 있는 이점은: 

• 함수 하나를 수정했다고 다른 함수가 망가질 위험이 사라짐
• 테스트 코드로 구석구석 증명하기도 쉬워짐
• 새로운 기능인 Update를 추가하고 싶다면 Sql을 상속하는 UpdateSql 클래스를 생성하면 손쉽게 추가할 수 있음
• OCP

 

클래스를 쪼개다 보면 (자연스레) 객체지향의 특징인 SOLID를 갖출 수 있다.

• 기존 기능을 변경할 때 시스템을 확장할 뿐 기존 코드를 변경하지 않는다.
• OCP(Open-Closed Principle) 개방-폐쇄 원칙: 
  • 확장에 대해 열려있고 수정에 대해서는 닫혀있어야 한다는 원칙
• 변경으로부터 격리; 결합도를 낮추면 유연성과 재사용성이 높아진다.
• DIP(Dependency Inversion Principle) 의존 역전 원칙:
  • 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안 되며, 저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존해야 한다는 것(추상화에 의존해야 한다)

---

참고) SOLID(객체 지향 설계)