[Clean Architecture] 설계 원칙 SOLID

1. SRP: 단일 책임 원칙

SRP 단일 책임 원칙은 단 하나의 일만 해야 한다는 원칙이 아니다.

=> SPR란 하나의 모듈은 오직 하나의 액터에 대해서만 책임져야 한다.

 

SRP 원칙을 위반하는 사례로 살펴보자.

 

징후 1: 우발적 중복

그림 7.1의 Employee 클래스를 보면 세개의 메소드를 갖고 있다. 

1. calculatePay() → CFO

2. reportHours() → COO

3. save() → CTO

 

이 클래스는 SRP를 위반하는데, 이들 세 가지 메소드가 서로 매우 다른 세 명의 액터를 책임지기 때문이다. 

이 설계의 문제점은 무엇일까?

만약 calculatePay 함수와 reportHours 함수가 a() 라는 함수를 공유하고 있다고 가정해보자.

이때 CFO팀에서 a() 함수의 로직을 변형시킬 일이 있다면? reportHours 함수를 사용하고 있던 COO 팀은 엉터리 원치않은 결과값을 받아보게 된다. 

 

 

징후 2: 병합

위와 똑같은 Employee 클래스에서 예를 들어보자.

CFO에서 기획이 변경되어 CFO 팀의 개발자가 코드를 수정하기 시작하고 동시에 COO에서도 기획이 변경되서 개발자가 코드를 수정하기 시작한다고 가정하자. 이들 변경사항은 서로 충돌하고 결과적으로 병합이 발생한다. 

최근 도구는 굉장히 뛰어나지만, 어떤 도구도 병합이 발생하는 모든 경우를 해결할 수는 없다. 병합 후에 CTO도 영향을 받게 되리라고 짐작해볼 수 있다. 

 

 

해결책

해결책은 데이터와 메서들르 분리하는 방식이다. 그림 7.3과 같이 메서드가 없는 간단한 데이터 구조인 EmployeeData 클래스를 만들어, 세 개의 클래스가 공유하도록 한다. 이렇게 바꾼다면, 세 클래스는 서로의 존재를 모르게 될 것이다.

 

이때, 단점도 발생하는데, 개발자가 세 가지 클래스를 인스턴스화 하고 추적해야한다는게 단점이다. 이럴때, Facade 패턴을 쓴다.

Facade?
퍼사드 패턴(Facade Pattern)은 구조 패턴(Structural Pattern)의 한 종류로써, 복잡한 서브 클래스들의 공통적인 기능을 정의하는 상위 수준의 인터페이스를 제공하는 패턴이다.

퍼사드 객체(Facade Object)는 서브 클래스의 코드에 의존하는 일을 감소시켜 주고, 복잡한 소프트웨어를 간단히 사용 할 수 있게 간단한 인터페이스를 제공해준다.

 

 

 

 

 

2. OCP: 개방-폐쇄 원칙

개방-폐쇄 원칙은 확장에는 열려 있어야하고, 변경에는 닫혀 있어야 한다.

 

즉, 소프트웨어 개체이 행위는 확장할수 있어야 하지만, 이때 개체를 변경해서는 안 된다.

만약 요구사항을 살짝 확장하는 데 소프트웨어를 엄청나게 수정해야한다면, 그 소프트웨어 시스템을 설계한 아키텍트는 엄청난 실패에 맞닥뜨린 것이다.

 

사례로 살펴보자.

 

사고 실험

재무제표를 웹 페이지로 보여주는 시스템이 있다고 생각해보자.

웹 페이지에 표시되는 데이터는 스크롤 할 수 있으며,

음수는 빨간색으로 출력한다.

 

이제 이해관계자가 동일한 정보를 보고서 형태로 변환해서 흑백 프린터로 출력해 달라고 요청했다고 가정해보자. 

 

이 보고서에는

• 페이지 번호
• 페이지마다 적절한 머리글과 바닥글
• 표의 각 열에는 레이블
• 음수는 괄호로 감싸기

가 포함되어야 한다.

 

이때 OCP를 따른다면 기존의 코드를 수정하지 않고 새로운 코드를 작성해야한다.

소프트웨어 아키텍처가 훌륭하다면 변경되는 코드의 양이 가능한 한 최소화가 될 것이다.

 

그림 8.2

 

 

그림 8.3

A 컴포넌트에서 발생한 변경으로부터 B 컴포넌트를 보호하려면 반드시 A 컴포넌트가B 컴포넌트에 의존해야 한다.

 

 

그림 8.3의 경우 Presenter에서 발생한 변경으로부터 Controller를 보호하고자 한다. 

그리고 View에서 발생한 변경으로부터 Presenter를 보호하고자 한다.

 

Interactor는 다른 모든 것에서 발생한 변경으로부터 보호하고자 한다.

 

interactor의 위치는 OCP를 가장 잘 준수하는 곳에 위치한다. Database, Controller, Presenter, View에서 발생한 어떤 변경도 Interactor에 영향을 주지 않는다.

 

왜 Interactor가 특별한 위치를 차지해야 하는가? 그 이유는 '업무 규칙' 을 포함하기 때문이다. 

 

Interactor는 가장 높은 수준의 개념이며, 따라서 최고의 보호를 받는다.

View는 가장 낮은 수준의 개념 중 하나이며, 따라서 거의 보호를 받지 못한다.

 

 

이것이 바로 아키텍처 수준에서 OCP가 동작하는 방식이다.

 

 

방향성 제어

그림 8.2에서 FinancialDataGatewat 인터페이스는 FinancialReportGenerator와 FinancialDataMapper 사이에 위치하는데, 이는 의존성을 역전시키기 위해서다. 

FinancialDataGateway 인터페이스가 없었다면, 의존성이 Interactor 컴포넌트에서 Database 컴포넌트로 바로 향하게 된다. FinalcialReport Presenter 인터페이스와 2개의 View 인터페이스도 같은 목적을 가진다.

 

 

정보 은닉

그림 8.2에서 FinancialReportRequester 인터페이스는 방향성 제어와는 다른 목적을 가진다.

 

이 인터페이스는 FinancialReportController가 Interactor 내부에 대해 너무 많이 알지 못하도록 막기 위해서 존재한다. 만약 이 인터페이스가 없었다면, Controller는 FinancialEntities에 대해 추이 종속성을 가지게 된다.

 

다시 말해, Controller에서 발생한 변경으로부터 Interactor를 보호하는 일의 우선순위가 가장 높지만, 반대로 Interactor에서 발생한 변경으로부터 Controller도 보호되기를 바란다. 이를 위해 Interactor 내부를 은닉한다.

 

 

결론

OCP의 목표는 시스템을 확장하기 쉬운 동시에 변경으로 인해 시스템이 너무 많은 영향을 받지 않도록 하는 데 있다.

이러한 목표를 달성하려면 시스템을 컴포넌트 단위로 분리하고, 저수준 컴포넌트에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있는 형태의 의존성 계층구조가 만들어지도록 해야 한다. 

 

 

3. LSP: 라스코프 치환 원칙

1988년 바바라 리스코프는 하위 타입을 아래와 같이 정의했다.

S 타입의 객체(o1), 각각에 대항하는 T 타입 객체(o2)가 있고, T 타입을 이용해서 정의한 모든 프로그램 P에서 o2의 자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면, S는 T의 하위 타입이다.

 

 

상속을 사용하도록 가이드하기

 

위 License라는 클래스는 calcFee()라는 메서드를 가지며, Billing 애플리케이션에서 이 메서드를 호출한다. 

License에는 PersonalLicense와 BusinessLicense라는 두 가지 '하위 타입'이 존재한다. 이들 두 하위 타입은 서로 다른 알고리즘을 이용해서 라이선스 비용을 계산한다. 

 

위 설계는 LSP를 준수한다. Billing 애플리케이션의 행위가 License 하위 타입 중 무엇을 사용하는지에 전혀 의존하지 않기 때문이다. 이들 하위 타입은 모두 License 타입을 치환할 수 있다.

 

 

앞서 본 것처럼 LSP는 상속을 사용하도록 가이드하는 방법 정도로 가이드되었다. 하지만 시간이 지나면서 LSP는 인터페이스와 구현체에도 적용되는 더 광범위한 소프트웨어 설계 원칙으로 변모해 왔다.

 

 

리스코프 치환 원칙은 개인적으로 책을 봐도 이해가 잘 되지 않아 유튜브 강의 내용을 정리해봤다.

 

예를 들어 Cat이라는 부모 클래스가 있고 Sub type들인 검은 고양이, 길고양이 클래스가 있다 생각해보자.

 

 

 

위 사진에서 볼 수 있듯이 Cat() 으로 생성하던걸 BlackCat() 즉 하위 타입으로 생성해도 프로그램이 돌아가는데 지장을 주지 않는다.

 

 

하지만 Fish 를 Cat의 서브 클래스로 생성한다 생각해보자. 물고기는 말할 수 없기 때문에 당연히 예외를 던질 것이고 sepak() 함수를 호출한 프로그램은 예외가 터질 것이다.

 

여기서 생각해볼 수 있는 것은 Cat 클래스는 Fish 클래스로 치환할 수 없고, LSP 원칙을 어긴 것이다. 

 

 

 

4. ISP: 인터페이스 분리 원칙

 

 

 

인터페이스 분리 원칙은 위 다이어그램에서 유래했다. 

 

다수의 사용자가 OPS 클래스의 오퍼레이션을 사용한다. 

• User1은 op1, 
• User2는 op2, 
• User3는 op3

만을 사용한다고 가정해보자. 그리고 OPS가 정적 타입 언어로 작성된 클래스라고 해보자. 

 

이 경우 User1에서는 op2와 op3를 전혀 사용하지 않음에도 User1의 소스 코드는 이 두 메서드에 의존하게 된다. 이러한 의존성으로 인해 User1과 관련된 코드는 변경되지 않았어도 OPS 클래스에서 op2의 소스 코드가 변경되면 User1도 다시 컴파일 후 새로 배포해야 한다. 

 

이러한 문제는 아래처럼 오퍼레이션을 인터페이스 단위로 분리하여 해결할 수 있다.

 

 

 

 

User1의 소스 코드는 U1Ops에 의존하지만 OPS에는 전혀 의존하지 않게 된다.

따라서 OPS에서 발생한 변경이 User1과는 전혀 관계없는 변경이라면, User1은 다시 컴파일하고 새로 배포하지 않아도 된다.

 

ISP와 언어

앞의 사례는 언어 타입에 의존한다. 정적 타입 언어는 사용자가 import, user 또는 include와 같은 타입 선언문을 사용하도록 강제한다. 이처럼 소스 코드에 포함된 include 선언문으로 인해 소스 코드 의존성이 발생하고, 이로 인해 재컴파일 또는 재배포가 강제된다.

 

루비나 파이썬과 같은 동적 타입 언어에서는 소스코드에 이러한 선언문이 존재하지 않는다.

대신 런타임에 추론이 발생한다. 따라서 소스코드 의존성이 아예 없으며, 재컴파일과 재배포가 필요없다.

동적 타입 언어를 사용하면 정적 타입 언어를 사용할 때보다 유연하며 결합도가 낮은 시스템을 만들 수 있는 이유는 바로 이 때문이다. 

 

이러한 사실로 인해 ISP를 아키텍처가 아니라, 언어와 관련된 문제라고 결론내릴 여지가 있다.

즉, ISP는 언어 종류에 따라 영향받는 정도가 다르다. 

 

그럼 JAVA는 어떨까??

자바의 경우 정적 타입 언어지만, op2 메서드가 변경되면 이를 사용하는 User2만 재컴파일하면 된다. 이는 자바가 비-final, 비 private 인스턴스 변수에 대해서는 호출할 정확한 메서드를 런타임에 결정하는 늦은(late binding)을 수행하기 때문이다. 컴파일타임에는 호환되는 시그니처의 메서드가 타입 계층구조 어딘가에 존재하는지까지만 확인한다.

 

 

결론

여기에서 배울 수 있는 교훈은 불필요한 짐을 실은 무언가에 의존하면 예상치도 못한 문제에 빠진다는 사실이다.

 

 

 

5. DIP: 의존성 역전 원칙

의존성 역전 원칙에서 말하는 '유연성이 극대화된 시스템'이란 소스코드 의존성이 추상에 의존하며 구체에는 의존하지 않는 시스템이다.

 

자바와 같은 정적 타입 언어에서 이 말은 use, import, include 구문은 오직 인터페이스나 추상 클래스 같은 추상적인 선언만을 참조해야 한다는 뜻이다. 구체적인 대상에는 절대로 의존해서는 안 된다.

 

루비나 파이썬 같은 동적 타입 언어에도 동일한 규칙이 적용된다.

소스 코드 의존 관계에서 구체 모듈은 참조해서는 안 된다. 하지만 이들 언어의 경우 구체 모듈이 무엇인지를 정의하기가 힘들다.

호출할 함수가 구현된 모듈이라면 참조하지 않기가 특히 어렵다.

 

이 아이디어는 확실히 비현실적이다.

소프트웨어 시스템이라면 구체적인 많은 장치에 의존하기 때문이다.

 

예를 들어 자바의 String은 구체 클래스이며, 이를 애써 추상 클래스로 만들려는 것은 현실성이 없다.

java.lang.String 구체 클래스에 대한 소스 코드 의존성은 벗어날 수도 없고, 벗어나서도 안 된다.

반면 String 클래스는 매우 안정적이다. 클래스가 변경되는 일은 거의 없으며, 있더라도 매우 엄격하게 통제된다. 따라서 프로그래머와 아키텍트는 String 클래스에서 변덕스러운 변경이 자주 발생하리라고 염려할 필요가 없다.

 

이러한 이유로 DIP를 논할 때 운영체제나 플랫폼 같이 안정성이 보장된 환경에 대해서는 무시하는 편이다.

우리는 이들 환경에 대한 의존성은 용납하는데, 변경되지 않는다면 의존할 수 있다는 사실을 이미 알고 있기 때문이다.

 

우리가 의존하지 않도록 피하고자 하는 것은 바로 변동성이 큰 구체적인 요소다.

 

그리고 이 구체적인 요소는 우리가 열심히 개발하는 중이라 자주 변경될 수 밖에 없는 모듈들이다.

 

 

안정된 추상화

추상 인터페이스에 변경이 생기면 이를 구체화한 구현체들도 따라서 수정해야 한다.

반대로 구체적인 구현체에 변경이 생기더라도 그 구현체가 구현하는 인터페이스는 항상, 좀 더 정확히 말하면 대다수의 경우 변경될 필요가 없다. 

 

따라서 인터페이스는 구현체보다 변동성이 낮다.

 

안정된 소프트웨어 아키텍처란?
변동성이 큰 구현체에 의존하는 일은 지양하고, 안정된 추상 인터페이스를 선호하는 아키텍처라는 뜻

 

 

• 변동성이 큰 구체 클래스를 참조하지 말라.
  • 대신 추상 인터페이스를 참조하라. 이 규칙은 언어가 정적 타입이든 동적 타입이든 관계없이 모두 적용된다.
    
    
  • 이 규칙은 객체 생성 방식을 강하게 제약하며, 일반적으로 추상 팩토리를 사용하도록 강제한다.

 

• 변동성이 큰 구체 클래스로부터 파생하지 말라.
  • 정적 타입 언어에서 상속은 소스 코드에 존재하는 모든 관계 중에서 가장 강력한 동시에 뻣뻣해서 변경하기 어렵다.
  • 동적 타입언어에서는 문제가 덜 되지만, 의존성을 가진다는 사실에는 변함이 없다.
  • 따라서 상속은 아주 신중하게 사용해야 한다.

 

• 구체 함수를 오버라이드 하지 말라.
  • 대체로 구체 함수는 소스 코드 의존성을 필요로 한다. 따라서 구체 함수를 오버라이드 하면 이러한 의존성을 제거 할 수 없게 되며, 실제로는 그 의존성을 상속하게 된다.
  • 이러한 의존성을 제거하려면, 차라리 추상 함수로 선언하고 구현체들에서 각자의 용도에 맞게 구현해야 한다.

 

• 구체적이며 변동성이 크다면 절대로 그 이름을 언급하지 말라
  • 이 실천법은 DIP 원칙을 다른 방식으로 풀어쓴 것이다.

 

 

조금 더 쉽게 예제를 들어 설명하면

 

위 두 코드엔 차이가 있다. 

첫번째 코드에는 Zoo 클래스(High Level)에서 고양이, 강아지 같은 Low Level에 의존하고 있다.

 

반면 아래 코드에선 Animal(abstract) 클래스를 갖고 있고 Zoo 클래스는 고양이, 강아지 같은 Low Level 클래스에 전혀 의존하고 있지 않다. 

 

두번째 코드를 그림으로 나타내면 아래와 같다. 

 

Cat, Dog 클래스가 Animal을 의존하면서 화살표 방향이 역전된다. 이때문에 dependency inversion이라 부른다.

 

 

 

Reference

https://www.youtube.com/watch?v=_G50Joyys_E