GoLang의 SOLID 원리 - 단일 책임 원칙(SRP)

No mundo do desenvolvimento de software, os princípios SOLID nos dizem como organizar funções e dados de forma que nossos códigos:

• Tolerem mudanças
• Sejam fáceis de entender
• Sejam a base de componentes que podem ser usados em muitos sistemas de software

O termo SOLID é um acrônimo para cinco postulados de design, descritos a seguir:

(S) Single Responsability Principle (Princípio da Responsabilidade Única): "Um módulo deve ter um, e apenas um motivo para mudar"
(O) Open/Closed Principle (Princípio Aberto/Fechado): "Um artefato de software deve estar aberto para extensão, mas fechado para modificações"
(L) Liskov Substitution Principle (Princípio de Substituição de Liskov): "Uma classe derivada deve ser substituível por sua classe base"
(I) Interface Segregation Principle (Principio da Segregação de Interface): "Uma classe não deve ser forçada a implementar interfaces e métodos que não utilizará"
(D) Dependency Inversion Principle (Principio da Inversão de Dependência): "Dependa de abstrações e não de implementações"

SOLID e GoLang

O SOLID é pensado para programação orientada a objetos, e é sabido que GoLang não é uma linguagem que adota esse paradigma. Contudo, podemos usar os recursos que ela disponibiliza para atender à metodologia POO. Por exemplo, Go não tem suporte de herança, mas a ideia pode ser compensada com seu suporte de composição. Da mesma forma, um tipo de polimorfismo pode ser criado usando interfaces.

Nesse artigo, o primeiro de uma série de 5, pretendo detalhar o primeiro princípio com exemplos que se aproximam de situações que nos deparamos no dia a dia.

Single Responsibility Principle (SRP)

Já sabemos o que o termo significa, agora é hora de aprender como implementá-lo em GoLang.
Nessa linguagem, poderíamos definir este princípio como “Uma função ou tipo deve ter um e apenas um trabalho, e uma e apenas uma responsabilidade”, vejamos o seguinte código:

Acima, temos uma struct que chamamos de userService. Ela tem duas propriedades: db que é responsável pela comunicação com um banco de dados relacional, e amqpChannel, que viabiliza a comunicação com o serviço de mensageria RabbitMQ.

UserService implementa um método chamado Create. Dentro desse método armazenamos as informações do usuário recebido no banco de dados e, em seguida, publicamos os dados no RabbitMQ.
Percebe-se que a responsabilidade do método Create no userService não é apenas uma, e sim, duas: armazenar uma informação no banco de dados e publicar uma mensagem numa fila do RabbitMQ.

Isso pode levar a vários problemas, como:

• Dificuldade de manutenção: se um dos requisitos mudar, como por exemplo, a forma como os dados do usuário são serializados, você terá que modificar a lógica do método Create, mesmo que isso não tenha nada a ver com a sua responsabilidade principal, que é salvar os dados no banco de dados.
• Dificuldade de teste: como o método Create tem duas responsabilidades diferentes, você terá que criar testes para cada uma delas, o que pode ser difícil e trabalhoso.
• Acoplamento desnecessário: a lógica de publicação dos dados do usuário em uma fila do RabbitMQ é totalmente independente da lógica de salvar esses dados num banco de dados. Misturar essas duas responsabilidades no mesmo método cria um acoplamento desnecessário.

No código a seguir, modificamos a estrutura para respeitar o SRP. Vejam só:

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

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

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

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

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

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

나중에 또 만나요 ​​여러분!

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

위 내용은 GoLang의 SOLID 원리 - 단일 책임 원칙(SRP)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!