[파이썬 클린코드] 4장 (SOLID 원칙) 정리

안녕하세요 Dibrary입니다. 이번에는 파이썬 클린코드의 4장 내용을 정리해보겠습니다.

4장은 객체지향적으로 코딩을 작성할 때 생각해 봐야 하는 원칙인 SOLID원칙을 설명하고 있습니다.

1. S (Single Responsibility Principle) 단일 책임 원칙

소프트웨어 컴포넌트(클래스)는 단 하나의 책임을 져야 한다는 것.

아래 코드 처럼 독립적인 동작을 하는 메서드를 하나의 클래스에 정의해버리면 안 된다. 

완전 처음에 개발했던 코드

이렇게 하나에 많은 기능을 집약해넣게 될 경우, 외부 요소에 의한 영향 최소화가 안 된다.

보다 응집력있고 작은 추상화가 가능해야 한다.

 

물론, '단일 책임 원칙'이라고 해서 클래스가 딱 하나의 메서드만을 가져야 한다는 것이 아니다.

 

---

2. O (Open/Close Principle) 개방 폐쇄 원칙

모듈의 확장에는 개방되어있어야 하고, 수정에는 폐쇄되어야 한다.

새 문제가 발생할 경우 새로운 것을 추가하기만 할 뿐 기존 코드는 그대로 유지해야 한다.

 

아래와 같은 코드가 있다고 가정하자. 

이 코드의 문제점은, 이벤트 유형을 결정하는 부분이 코드(identify_event)에 집중되어 있다는 것이다.
또, 새 이벤트가 추가되면 elif를 쓰거나 해서 코드에 수정이 가해지게 된다.

 

새 이벤트가 추가되면 수정하지 않고, '기능 추가'를 통해 코드를 바꿀 수 있는 방법은 아래와 같다.

staticmethod로 정의함으로써 이벤트 종류가 새롭게 추가된다 하더라도 identify_event 부분의 코드는 수정할 것이 없다.

 

---

3. L (Liskov substitution Principle) 리스코프 치환 원칙

이 원칙은 객체 타입이 유지해야 하는 일련의 특성을 말한다.

어떤 클래스든 클라이언트는 특별한 주의를 기울이지 않고도 하위 타입을 사용할 수 있어야 한다.

하위클래스는 상위클래스에서 정의한 계약을 따르도록 설계해야 한다.

 

---

4. I (Interface segregation Principle) 인터페이스 분리 원칙

인터페이스는 객체가 노출하는 메서드의 집합이다.

인터페이스 분리 원칙은 '다중 메서드를 가진 인터페이스'가 있을 때, 더 적은 수의 메서드를 가진 여러 인터페이스로 분할하는 것이 좋다는 것이다. 여기서 무조건 갯수를 줄이라는 의미가 아니라 '동작과 책임' 측면에서 S원칙을 만족할 수 있게 분할하라는 것.

 

인터페이스는 크기가 작을수록 좋다. 그래야 특정 기능에 문제가 생겼을 경우 '빠르게' 찾을 수 있고, 수정 및 테스트가 이뤄질 수 있다.

 

---

5. D (Dependency inversion Principle) 의존성 역전 원칙

의존성을 역전시킨다는 것은 코드가 세부 사항이나 구체적 구현에 적응하도록 하지 않고, 대신에 API같은 것에 적응하게 하는 것이다.

만일 A가 B의 인스턴스를 사용하는데, 의존도가 크다면 B 코드가 변경될경우 원래의 코드가 쉽게 깨진다.
그래서 이런 경우에 인터페이스를 구성하고 코드가 B의 구체적 구현에 의존하지 않게 해야 한다.

의존성 주입 = 의존성을 동적으로 제공하는것 지칭