Princípio da Responsabilidade Única - Princípios S.O.L.I.D.

O que são os princípios S.O.L.I.D.?

단단한. 소프트웨어에 대한 디자인의 5번째 원칙, voltados à programação orientada a objetos. Eles foram introduzidos por Robert C. Martin em um artigo . Estes princípios ajudam a escrever um codigo melhor nos quesitos de entendimento, manutenção e melhor reproveitamento.


Esse acronimo significa:

단일 책임 원칙(Principio da Responsabilidade Única)

개방/폐쇄 원칙(Principio do Aberto/Fechado)

Liskov 치환 원리(Princípio da Substituição de Liskov)

인터페이스 분리 원칙(Princípio da Segregação de Interfaces)

종속성 반전 원리(Princípio da Inversão de Dependências)

Neste artigo será apresentado o primeiro dos princípios do S.O.L.I.D., o 단일 책임 원칙. Usaremos a linguagem C# para todos os exemplos.

단일 책임 원칙(SRP)

Uma classe deve ter um e somente um motivo para mudar, ou seja, ela deve ser responsável por apenas uma parte específica de um sistema.

Isso significa que cada classe deve ser especializada, podendo fazer apenas um trabalho e não vários. Assim, focando na sua atividade 교장.

Quaando uma classe tem muitas responsabilidades, Existing mais chances dela precisar de ser modificada e também de possuir mais bugs.

모범 사례

Vamos usar exemplo inspirado na franquia dos jogos do Mario, da Nintendo. Abaixo temos a class Cogumelo, ela Representativea os itens de cogumelo que dão um benefício ao entrar em contato com o jogador.

Esta classe contém três métodos: darBeneficio() , sumir() e somBeneficio() . Dessa forma, ela é responsável por dar o benefício ao Mario, e ao entrar em contato com o personagem o item desaparece e reproduz o som de feedback. Porem, função principal do item é de dar uma vantagem a quem o obtém.

using UnityEngine;
using System.Collections;

public class Cogumelo : MonoBehaviour
{
    public int id;
    public string cor;

    public void darBeneficio(){
        //lógica para atribuir o beneficio ao Mário
    }
    public void sumir(){
        //lógica para desaparecer o cogumelo
    }
    public void somBeneficio(){
        //lógica para reproduzir o som beneficio na tela
    }
}

Nessa abordagem, classe Cogumelo tem mais de uma ação e responsabilidade. No caso da modificação do som de feedback, por exemplo, isso acarretaria em uma mudança na classe Cogumelo como um todo. Consequentemente um erro em somBeneficio(), Iria impactar os outros metodos da classe. 버그가 발생할 가능성이 있습니다.

Além disso, ao reutilizar os metodos somBeneficio() e sumir() em outros itens faria com que instâncias de Cogumelo existam em outras classes. Assim, mais classes seriam dependentes de Cogumelo, o que gera um acoplamento maior no sistema e tornam mudanças mais difíceis. Outro fator é que essas outras classes teriam acesso ao método darBeneficio() , mesmo sem precisar dele.

Aplicando o princípio da responsabilidade única, separando as responsabilidades pelos comportamentos que são realizados, obtemos a modificação abaixo.

using UnityEngine;
using System.Collections;

public class Cogumelo : MonoBehaviour
{
    public int id;
    public string cor;

    public void darBeneficio(){
        //lógica para dar beneficio
    }
}

public class Some : MonoBehaviour{
    public void sumir(){
        //lógica para desaparecer o cogumelo
    } 
}

public class ReprodutorSom : MonoBehaviour{
    public void somBeneficio(){
        //lógica para reproduzir o som beneficio na tela
    }     
}

Dessa forma acima, é possível reutilizar as classes em outros objetos do jogo, como as moedas, blocos e outros itens diferentes. Também com esta modificação todas as três classes ficam mais coesas, tendo apenas uma responsabilidade, o que facilita a manutenção do codigo e evita mais bugs no futuro.

Um dos possíveis problemas que podem acontecer ao não usar o SRP, é o alto acoplamento entre classes, dificuldade de repoveitamento de codigo e a falta de coesão. Estes três fatores atrapalham a realização de futuras modificações, deixando as classes muito dependentes entre si e dificultando o seu entendimento.

로고, 단일 책임 원칙 ajuda na manutenção de um projeto e na legibilidade dele. Além de ser base para outros princípios e padrões de projetos, como o Factory, Builder e o Command.