소프트웨어 개발 세계에서 SOLID 원칙은 코드가 다음과 같이 기능과 데이터를 구성하는 방법을 알려줍니다.

• 변경 허용
• 이해하기 쉽게 작성하세요.
• 다양한 소프트웨어 시스템에서 사용할 수 있는 구성요소의 기반이 됩니다.

SOLID라는 용어는 아래에 설명된 5가지 설계 가정의 약어입니다.

(S) 단일 책임 원칙: "모듈에는 변경 이유가 하나만 있어야 합니다."
(O) 개방/폐쇄 원칙: "소프트웨어 아티팩트는 확장을 위해 열려야 하지만 수정을 위해서는 닫혀 있어야 합니다."
(L) Liskov 대체 원칙: "파생 클래스는 기본 클래스로 대체 가능해야 합니다."
(I) 인터페이스 분리 원칙: "클래스는 사용하지 않을 인터페이스와 메서드를 구현하도록 강요해서는 안 됩니다."
(D) 종속성 반전 원칙: "구현이 아닌 추상화에 의존"

SOLID와 GoLang

SOLID는 객체 지향 프로그래밍을 위해 설계되었으며 GoLang은 이러한 패러다임을 채택한 언어가 아닌 것으로 알려져 있습니다. 그러나 OOP 방법론을 충족하기 위해 제공되는 리소스를 사용할 수 있습니다. 예를 들어 Go에는 상속 지원이 없지만 구성 지원으로 아이디어를 보완할 수 있습니다. 마찬가지로 인터페이스를 사용하여 일종의 다형성을 만들 수 있습니다.

5개의 시리즈 중 첫 번째인 이 기사에서는 우리가 일상적으로 접하는 상황에 가까운 예를 들어 첫 번째 원칙을 자세히 설명하려고 합니다.

단일 책임 원칙(SRP)

우리는 이미 이 용어가 무엇을 의미하는지 알고 있습니다. 이제 GoLang에서 이를 구현하는 방법을 배울 차례입니다.
이 언어에서는 이 원칙을 "함수나 유형은 단 하나의 작업과 단 하나의 책임을 가져야 합니다"라고 정의할 수 있습니다. 다음 코드를 살펴보겠습니다.

위에 userService라는 구조체가 있습니다. 여기에는 관계형 데이터베이스와의 통신을 담당하는 db와 RabbitMQ 메시징 서비스와의 통신을 지원하는 amqpChannel라는 두 가지 속성이 있습니다.

UserService는 Create라는 메서드를 구현합니다. 이 방법에서는 수신된 사용자 정보를 데이터베이스에 저장한 다음 해당 데이터를 RabbitMQ에 게시합니다.
userService에서 Create 메소드의 책임은 하나가 아니라 데이터베이스에 정보를 저장하고 RabbitMQ 대기열에 메시지를 게시하는 두 가지임을 알 수 있습니다.

이로 인해 다음과 같은 여러 가지 문제가 발생할 수 있습니다.

• 유지 관리 어려움: 사용자 데이터가 직렬화되는 방식과 같은 요구 사항 중 하나가 변경되면 Create 메서드의 논리를 수정해야 합니다. 이것이 주요 책임과 관련이 없더라도 마찬가지입니다. 데이터베이스에 데이터를 저장합니다.
• 테스트 난이도: Create 메서드에는 서로 다른 두 가지 책임이 있으므로 각각에 대한 테스트를 만들어야 하며 이는 어렵고 힘들 수 있습니다.
• 불필요한 결합: RabbitMQ 대기열에 사용자 데이터를 게시하는 논리는 이 데이터를 데이터베이스에 저장하는 논리와 완전히 독립적입니다. 동일한 방법으로 이 두 가지 책임을 혼합하면 불필요한 결합이 발생합니다.

다음 코드에서는 SRP를 준수하도록 구조를 수정합니다. 확인 해봐:

책임을 세 가지 별개의 부분으로 분리했습니다. 사용자를 데이터베이스에 유지하는 저장소 UserRepository, RabbitMQ에 메시지를 보내는 게시자 UserPublisher, 이 두 가지 작업을 조율하는 서비스 UserService.

이러한 방식으로 각 구성 요소는 특정하고 독립적인 작업을 담당하여 코드의 유지 관리 및 발전을 촉진할 뿐만 아니라 이러한 각 부분을 다른 부분에 영향을 주지 않고 교체하거나 개선할 수 있습니다. 예를 들어, 사용된 데이터베이스를 변경해야 하는 경우 저장소만 교체하면 됩니다. 소통의 형태를 바꿔야 한다면 출판사만 바꾸면 됩니다.

두 가지 서로 다른 작업을 수행하는 것과 실행을 위임하는 것 사이에는 미묘한 차이가 있다는 점을 언급할 가치가 있습니다. userService.Create의 원래 예에서는 두 작업이 한 곳에서 수행되어 단일 책임 원칙을 위반했습니다. 리팩터링 후 실행을 다른 구조체에 위임했으며 Create 메서드는 이 흐름을 조정하는 역할만 담당했습니다.

이 예에서 SRP를 적용하기 위해 우리는 다른 SOLID 원칙 중 일부도 구현하게 되었습니다.

• 인터페이스 분리 원칙(ISP): 각 인터페이스는 단일 책임을 나타냅니다. UserRepository와 UserPublisher는 모두 단일 책임을 나타내는 메서드가 하나만 있는 인터페이스입니다.
• DIP(종속성 역전 원칙): userService 구조체는 구체적인 구현이 아닌 추상화(인터페이스)에 의존합니다. 즉, UserRepository 및 UserPublisher의 특정 구현을 알지 못합니다. 그들이 구현하는 인터페이스.
• 개방/폐쇄 원칙(OCP): userService를 수정하지 않고도 새 저장소나 게시자를 쉽게 추가할 수 있으므로 코드는 확장을 위해 열려 있습니다.

이 시리즈의 다음 기사에서는 구체적인 예를 들어 각 항목에 대해 더 자세히 설명하겠습니다.

나중에 뵙겠습니다 여러분!

참조:
SOLID: 객체 지향 디자인의 첫 5가지 원칙
Clean Coder 블로그 - 단일 책임 원칙