chap10-클래스 잘 설계하기

목차

1. 캡슐화되어야 한다
2. 단일 책임 원칙
3. 낮은 결합도와 높은 응집도
4. 변경하기 쉬워야 한다

1. 캡슐화되어야 한다

캡슐화 : 객체의 실제 구현을 외부로부터 감추는 방식

• 클래스를 개발할 때 기본적으로 구현을 감추고, 외부 객체와 상호작용하는 부분만 노출한다.
• 외부의 잘못된 사용을 방지한다.
• 필드를 private으로 제한, get으로 읽기.
• 수정은 push, pop 메서드를 통해서 일어나도록 제한.

2. 단일 책임 원칙

클래스는 작아야 한다

• 함수와 마찬가지로 클래스도 작아야 한다.
• 함수는 라인 수로 크기를 측정했는데, 클래스는 맡은 책임의 수로 크기를 측정한다.
• 클래스 설명은 만일(if), 그리고(and), 또는(or), 하지만(but)을 사용하지 않고 25단어 내외로 가능해야 한다.
  => 책임이 한 가지여야 한다.

단일 책임 원칙

클래스가 맡은 책임이 한 개인가

• SRP해야 한다. 자잘한 단일 클래스가 많아지면 큰 그림을 이해하기 어려울 수 있다. 하지만 작은 클래스가 많은 시스템이든 큰 클래스가
  몇 개뿐인 시스템이든 돌아가는 부품은 그 수가 비슷하다.
• "도구상자를 어떻게 관리하고 싶은가? 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 넣고 싶은가? 아니면 큰 서랍 몇 개를 두고
  모두를 던져 넣고 싶은가?"
• 큼직한 다목적 클래스 몇 개로 이뤄진 시스템은 (변경을 가할 때) 당장 알 필요가 없는 사실까지 들이밀어 독자를 방해한다.
• 작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유도 하나다. 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.

단일 책임 원칙 (SRP) 중요성

3. 낮은 결합도와 높은 응집도

결합도와 응집도

낮은 결합도, 높은 응집도

결합도는 낮을수록, 응집도는 높을수록 유지보수성이 좋다

결합도는 낮아야 한다

• 시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아진다.
• DIP - 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다.
• 추상화를 이용하면 테스트 코드 짜기에 용이하다.*

낮은 결합도

• 테스트 결과가 늘 같도록 한다. 그러나 확장될 가능성이 적다면 일단은 결합하고, 나중에 추상화해도 좋다. 객체를 Mocking 하면 변경되는 클래스도 테스트할 수 있다.

높은 응집도

응집도는 높아야 한다

• 클래스는 인스턴스 변수 수가 적어야 한다. 메서드는 인스턴스 변수를 하나 이상 사용해야 한다. 메서드가 인스턴스 변수를 많이 사용할수록 응집도가 높다.
• 응집도가 높다 = 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다 = 서로 관계있는 애들만 모여있다.
• 클래스가 응집도를 잃어간다면 함수를 쪼개야 한다.

4. 변경하기 쉬워야 한다

클래스는 변경하기 쉬워야 한다

Update문을 추가해야 한다면?
새로운 SQL을 추가할 때도 수정이 발생하고, 기존 SQL문을 수정할 때도 수정이 발생하므로 OCP에 위반된다.

• 공개 인터페이스를 전부 SQL 클래스에서 파생하는 클래스로 만들고, 비공개 메서드는 해당 클래스로 옮기고, 공통된 인터페이스는 따로 클래스로 뺐다.
• 기존 클래스를 건드리지 않아도 된다.