[Clean Architecture] SOLID 원칙 (객체지향 설계원칙)

SOLID 원칙이란?

SRP, OCP, LSP, ISP, DIP등, 5개 원칙을 SOLID 원칙이라고 합니다 (아래의 5개 원칙 설명하겠습니다)

즉, "너가 만약 객체지향언어(Java 등)로 객체지향적으로 프로그램 만들어서, 문제를 푸려고 할때, 몇가지 원칙을 따르는게 좋을 걸?" 이라고 마이클 페더스가 정의한 원칙이 SOLID 원칙입니다.

 

 좋은 SW 아키텍쳐들이 따르는 원칙들이 있습니다. 그것이 SOLID 원칙입니다. 사실 SOLID 원칙은 중간수준의 모듈 수준에서 SW를 설계할때 쓰는 원칙입니다. 여기서 중간수준은 뭐고 모듈은 뭘까요?

 

 중간수준은 모듈 수준에서의 작업을 말합니다. 모듈은 소스파일 혹은 클래스(데이터와 함수의 집합체) 단위를 말합니다.

코드 구현부에 가까울수록 저수준, 업무규칙(Business Rule) (고객 요구사항)에 가까울수록 고수준이라고 합니다.

 

 이제, 아래의 SOLID 원칙의 5가지를 설명하겠습니다.

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

요약

하나의 모듈은 하나의 액터에 대해 책임을 져야 한다.

(액터란? 하나의 이해집단(사용자 집단). 해당 변경을 요구하는 한명 이상의 사용자)

즉 아래의 말과 같다.

"아 정렬 알고리즘이 변경되어야하는데, 그러한 기능 변경은 sort class에서만 이루어져야해!, 다른 클래스에서의 변경을 일어나지 않도록 설계하자." 라는 원칙이다.

 

상세 설명

 예를 들어, Car클래스는 Car를 이용하는 사람 혹은 Car에 대한 이해관계자'만' 책임을 져야합니다.

 만약, Car클래스 안에 다른 이해관계자(자전거, 타이어, 범퍼 등등)이 책임 혹은 관여를 하면 문제가 발생합니다. (Car클래스 안에 멤버로 Tire 클래스를 가질 순 있지만 Car란 모듈이 Tire 모듈의 변경에 대해 책임을 지면 안됩니다).

 SRP는 메서드와 클래스 수준의 원칙입니다.

 즉, 어떤 메서드가 서로 다른 이유로 변경이 된다면 그 메서드는 다른 클래스로 분리해야한다.

 

2. OCP  (Open-Closed Principle, 개방-폐쇄 원칙)

요약

모듈수준의 개발에서 확장에는 열려야되고, 수정에는 닫혀야한다.

(즉, 소스코드를 변경할때는 추가하는 코드를 추가하는 방향으로 가는 것이 좋다. 수정하는 방향 대신)

즉, 아래와 말과 같다.

"기능을 추가하고 싶어? 그럼 소스코드를 수정하지말고, 메서드로 추가해서 개발하는 설계를 하자."

 

상세 설명

다른 목적으로 변경되는 요소를 적절하게 분리하고(SRP) 이들 요소 사의 의존성을 체계화함(의존성 역전 원칙) 으로써 변경량을 최소화할 수 있다.

 

3. LSP  (Liskov Substitution Principle, 리스코프 치환 법칙)

요약

하위타입의 클래스는 상위타입의 클래스로 치환이 가능해야 한다.

(서브타입은 베이스타입으로 치환이 가능해야한다 원칙)

즉, 아래의 말과 같다.

"공통 기능이 있으면, 그걸 상위 타입의 클래스로 치환하게끔 설계하자!"

 

 

4. ISP  (Interface Segregation Principle, 인터페이스 분리 원칙)

요약

하나의 오퍼레이션은 하나의 인터페이스로 분리해서 모듈을 구성해야 한다.

(즉, 사용하지 않은 동작, 기능에 해서는 의존(상속)하면 안된다.)

즉, "사용하지 않는 메소드를 상속받지 않게 설계하자, 음. 자식 클래스는 쓰지도 않는 메소드를, 부모로부터 받지 말자!" 라는 말이다.

 

5. DIP  (Dependency Inversion Principle, 의존성 역전 원칙)  (중요)

요약

추상에 의존하고 구체에는 의존하지 않는 시스템으로 지향해야한다.

(추상은 interface, abstract class를 말함, 구체는 객체 혹은 객체생성을 말함)

 

"자바를 예시로, 너가 특정 객체를 사용할 때, 보통 그냥 new 객체() 이렇게 사용하지 않니?

근데, 그거 대신에, 해당 객체의 상위 클래스에 해당하는, Interface나 abstract 클래스의 객체를 생성해서, 메소드 호출하도록 설계하자!"

 

상세 설명

 구체에 의존한다는 것은 무엇을 의미하는가? 직접 객체를 생성해서 사용한다는 의미이다.

또한, 고수준 정책을 구현하는 코드는 저수준 세부사항을 구현하는 코드에 절대 의존하면 안된다.

대신 세부사항이 정책에 의존해야합니다. 즉, 정책이 세부사항을 의존하면 문제가 발생하게 된다.

 

출처

Clean Architecture  로버트 C. 마틴