SOLID 5가지 설계 원칙

객체지향 설계 개념

• 클래스(class): 공통되는 것들을 묶어서 대표적인 이름을 붙인 것(추상화 결과)
• 인스턴스(instance): 클래스가 메모리 공간에 할당된 실체
• 객체(object): 명확한 의미를 담고 있는 대상(설계자 관점), 클래스에서 생성된 변수(개발자 관점), 유일한 식별자, 상태 존재, 연산가능한 메서드

클래스 class	객체 object
핸드폰 설계도	핸드폰
자동차 설계도	자동차
붕어빵 틀	붕어빵

---

SOLID

• 객체 지향 프로그래밍(OOP: Object Oriented Programming) 대표적 원칙

SOLID

 

---

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

• 하나의 클래스는 하나의 책임만 가져야 함
• 클래스가 제공하는 모든 서비스(methods)는 그 책임을 수행하는데 집중함
• 환경이 바뀌어서 클래스를 변경해야 하는 이유는 오직 하나 뿐이어야 함
  • 환경 변화로 하나의 클래스가 여러 책임을 갖는 경우 -> 클래스 분할
• 비교적 단순한 원칙
• 복잡한 프로세스 구현하거나 경험이 부족할 경우 지키기 어려움
• 대부분의 SW 위협 원인이 SRP 미준수에서 비롯되는 경우 많음
• 책임이란 기준이 모호하기 때문에 변경을 책임의 기준으로 삼으면 설계에 용이할 수 있음
• 어떠한 역할에 대해 변경사항이 발생했을때, 영향을 받는 기능만 모아둔 클래스라면 동일한 책임을 지닌 기능이 모인 집합으로써 SRP 원칙이 적용된 설계로 볼 수 있다
• 이처럼 변경사항이 있을때, 애플리케이션의 파급 효과가 적으면 SRP 원칙을 잘 따는 것이라고 볼 수 있다

하나의 클래스에 너무 많은 기능이나 목적을 넣지 말자는 의미

 

SRP 장점

• 클래스 책임 영역 확실 -> 하나의 책임 변경에 따른 연쇄 변경에서 자유로움
• 응집도(cohesion) 강화, 결합도(coupling) 약화, 가독성 향상, 유지보수 용이

 

SRP 준수 전략

• 중복된 책임은 추상 클래스로 표현
• 기존의 클래스로 해결할 수 없다면 새로운 클래스 구현

---

개방 폐쇄의 원칙(OCP: Open Closed Principle)

• 확장(상속)에는 열려 있어야 하고 변경에는 닫혀 있어야 함
• 변경을 위한 비용(삽질..) 최소화, 확장을 위한 비용 극대화(쉽게)
  • 요구사항의  변경이 발생하더라도 기존 요소의 수정을 발행하지 않아야 함
  • 기존 요소를 쉽게 재활용해서 쉽게 확장할 수 있어야 함
• 추상화/다향성 핵심
• 객체지향 설계의 핵심 메커니즘
• 변화로부터 시작된 삽질
  • 변화를 막을 수 있는 사람 없음
  • 그러나 개발자를 괴롭힐 변화를 그대로 수용하기보다 적절히 대응할 전략 필요함
• 접근 방법
  • 변하지 않는 것과 변하게 될 것을 모듈로 구분
  • 이 모듈이 만나는 지점에 인터페이스 정의
  • 인터페이스에서 정의한 대로 구현(코딩)

---

리스코프 교환(치환)의 원칙(LSP: Liskov Substitution Principle)

• 기반 클래스는 파생 클래스로 대체할 수 있어야 함
• 서브 타입(자식)은 언제나 기반 타입(부모)으로 교체 가능해야함
• 서브 타입은 언제나 기반 타입과 호환될 수 있어야 함

• 자동차 클래스 구현
• 상속받아 다양한 종류의 자동차 구현
• 헬리콥터를 구현했다면 -> IS-A 관계 성립 안됨

• 부모 클래스 인스턴스 자리에 자식 클래스의 인스턴스가 들어가도 작동해야됨
  • 자식이 부모 자리에서 작동하려면 부모와 동일하게 행동해야함-> 자식은 부모의 행동 규약 준수해야함
  • 부모 클래스의 속성과 메서드를 그대로 물려받으면 아무 문제 없음

• 문제가 발생하는 경우 -> 대부분은 오버라이딩(overriding) 과정에서 발생
  • 오버라이딩 과정에서 변수타입 변경, 메서드의 파라미터나 리턴값 변경
  • 부모의 의도와 다르게 메서드를 변경하는 오버라이딩

 

LSP이론

 

문제 발생할 경우 해결방법

• 추상클래스, 인터페이스 활용
• 두 객체가 하는 일에 무언가를 추가해야 한다면 상속 활용

하는 일 같은 경우	하나의 클래스로 구성하고 구분 필드 추가
하는 일 다른 경우	별개의 클래스로 구성

SOLID 5개 원칙 중 제일 이해하기 어려움

---

인터페이스 분리의 원칙(ISP: Interface Segregation Principle)

• 하나의 일반적인 인터페이스보다는 구체적인 여러 개의 인터페이스가 낫다
• 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 함
• 어떤 클래스가 다른 클래스에 종속될 경우, 최소한의 인터페이스만 사용
• 인터페이스를 다수의 작은 단위로 구분, 사용자는 자신이 필요한 인터페이스만 사용하도록 구현

문제 발생할 경우 해결방법

• Inheritance(상속)을 이용한 해결
• Composition 이용한 해결

---

의존 관계 역전의 원칙(DIP: Dependency Inversion Principle)

• 클라이언트는 구체 클래스가 아닌 추상 클래스(인터페이스)에 의존해야 함
• 상위 모듈은 하위 모듈에 의존해서는 안됨(상위/하위 모듈 모두 추상화에 의존해야함)
• 클래스 사이에서 의존관계를 맺을 때, 쉽게 변하는 것보다 변화가 없는 것(변하기 어려운 것)에 의존하라는 의미

 

 

---

참고자료

Uncle Bob's SOLID principles made easy 🍀 - in Python!

소프트웨어 꼰대 강의, SOLID 원칙