A utilização dos princípios SOLID no desenvolvimento de

software
Artur Augusto Carvalho da Silva1, João Antonio Dias Lopes2, Victor Gabriel Leão
Guerra3

Curso Técnico em Informática – Instituto Federal Minas Gerais – Campus São João
Evangelista (IFMG-SJE)
{0055763@academico.ifmg.edu.br, 0062899@academico.ifmg.edu.br,
0062919@academico.ifmg.edu.br

Resumo. O presente artigo procura investigar os princípios SOLID e suas

aplicações no desenvolvimento de software, que deve seguir padrões pré-
determinados para maximizar a sua qualidade, assim como para assegurar
um desenvolvimento robusto. Os princípios SOLID mostram-se especialmente
pertinentes no desenvolvimento de software contemporâneo, estando
relacionado à POO (Programação Orientada a Objetos).

1. Introdução
Os métodos de desenvolvimento de software nos ajudam a diminuir os custos e o tempo
necessário no processo de desenvolvimento de software. De acordo com Vicenzi
(2004), “As técnicas e critérios de teste fornecem ao testador uma abordagem
sistema´tica e teoricamente fundamentada, al´em de constituírem um mecanismo que
pode auxiliar a avaliar a qualidade da atividade de teste. As técnicas de teste são
classificadas em funcional, estrutural e baseada em defeitos. Do ponto de vista
comportamental do sistema, tem-se o teste baseado em m´aquinas de estados finitos,
muito utilizado na a´rea de protocolos de comunica¸cão e no contexto do paradigma
Orientado a Objetos.” Para ajudar no desenvolvimento, os princípios SOLID foram
idealizados na década de 90. Para Martin (2017), “os princípios SOLID nos dizem como
organizar nossas funções e estrutura de dados em classes e como essas classes devem
ser interconectadas.” Ainda segundo Martin (2017), “os principais objetivos dos
princípios SOLID é criar um sistema que suporte alterações e seja fácil de entender”.
Para compreender os princípios SOLID, é preciso primeiro compreender o que é a
Programação Orientada a Objetos e quais são as suas funções. De acordo com Ramos
(2014), “A orientação a objetos é uma técnica de modelagem que contém diversos
conceitos que são adequados para os princípios de desenvolvimento de software. Além
disso, ao usar a orientação a objetos o sistema é modelado como objetos que de alguma
forma estão relacionados. Como os humanos estão acostumados com objetos na vida
real, fica simples pensar da mesma forma ao modelar um sistema. A orientação a objeto
é um conjunto de encapsulamento, herança e polimorfismo. O encapsulamento é uma
forma de esconder dados. Herança é a simples redeclaração de um grupo de variáveis e
funções em um escopo. O polimorfismo é uma forma de fazer com que um objeto tenha
várias formas, um exemplo seria um objeto que possui a função de ler dados e ele
consegue ler esses dados independente do dispositivo que está os fornecendo”. A partir
disso, são desenvolvidos os princípios SOLID, que serão estudados nesse artigo.
2. Revisão teórica

Os princípios SOLID são divididos entre cinco, SRP (Single responsibility principle),
OCP (Open Closed Principle), LSP (Liskov substitution principle), ISP (Interface
Segregation Principle) e DIP (Dependency Inversion principle). Todos esses princípios
são importantes durante o processo de desenvolvimento com a POO.

2.1. SOLID
De acordo com Pires (2013), “SOLID é um acrônimo de cinco princípios da
programação orientada a objetos, introduzido por Robert C. Martin no livro Princípios
de Design e Padrões de Design”. Este documento irá discutir os aspectos do primeiro
acrônimo do SOLID: Princípio de Responsabilidade Única e sua aplicação.

2.1.1. SRP (Princípio da responsabilidade única)

O princípio da responsabilidade única (SRP) propõe que cada classe deve responder a
uma única e determinada função. Portanto, se uma classe foi responsável por cadastrar
um novo cliente, ela apenas cadastra esse cliente e nada além disso. Segundo Ramos
(2022) “Nunca deve haver mais de um motivo para uma classe mudar. Se houver mais
de um motivo para mudar uma classe, então considera-se que essa classe possui mais de
uma responsabilidade, o que resulta em alto acoplamento. Este tipo de acoplamento leva
a projetos frágeis que podem quebrar de formas inesperadas para quaisquer requisitos de
mudança”.

3. Estudo de caso
Não é de hoje que grandes e pequenas empresas produzem seus softwares e
disponibilizam ao mercado consumidor, mas qual é a “fórmula” com que eles são
produzidos? Provavelmente possuem, ou pelo menos deveriam possuir um padrão de
projeto. Design patterns fornecem manutenibilidade ao software além da gigantesca
simples organização às classes. O SOLID é o melhor e mais usado padrão para a
facilitação na programação orientada a objetos e estruturação do talhe do produto. O
Princípio de Responsabilidade Única (S - Single Responsiblity Principle) é
imprescindível na estrutura de um aplicativo porque a implementação de software sem
um suporte crucial (como o SOLID) pode levar à baixa qualidade do produto, laboriosa
manutenção e reveses de desempenho. Como primeiro princípio, não apenas se obtém
uma codificação “mais impoluta”, mas o processo de execução do software também
alcança qualidade, incorporando divisão significativa e melhor estrutura funcional do
projeto.
Preferencialmente, os design patterns são estabelecidos e demonstrados no início do
projeto para que todos os membros da equipe saibam sobre eles. No entanto, Pressman
(2011) destaca que uma das fases mais difíceis para todos os indivíduos envolvidos no
sistema é aquela responsável por investigar e colocar em prática padrões que realmente
atendam às suas necessidades. Portanto, este estudo de caso tem o desígnio de
esclarecer o primeiro princípio SOLID e sua importância para os desenvolvedores. O
princípio da responsabilidade única legitima e alega que toda classe deve possuir
determinada função, um só papel. Para ilustrar, uma classe deve possuir apenas uma
tarefa, um motivo para achar-se. Se determinada classe for esboçada para realizar o
cadastro de automóveis aéreos, deve cumprir o cadastro de automóveis aéreos somente.
Isso arrisca-se em nossas mentes como acessório ou até mesmo como chatice, mas o uso
desse arquétipo de estruturação de desenvolvimento de software se faz vital em seu
molde. Isso é certificado para a criação de um produto de qualidade e melhor
compreensão dos seus códigos.
Este estudo de caso analisa de forma prática a diferença entre desenvolver um código
que não usa o princípio de responsabilidade única e um código que o usa por meio do
framework .NET e da linguagem de programação C#. O referido ensaio exemplificará a
forma correta de aplicar o Princípio da Responsabilidade Única em um quefazer de
desenvolvimento de software.
A compilação a seguir revela o ultraje ao SOLID, especificamente ao princípio da
responsabilidade única.

namespace DesrespeitoS.SOLID
{
public class Produto
{
public int Id { get; set; }
public string Nome { get; set; }
public string Descricao { get; set; }
public double Preco { get; set; }
public int Quantidade { get; set; }

public void Adicionar (Produto produto)

{
if (produto. Id == 0)
Console.WriteLine("Não foi possível adicionar o produto pois o Id está vazio");
else if (String.IsNullOrEmpty(produto.Nome))
Console.WriteLine("Não foi possível adicionar o produto pois o nome está vazio");
else if (String.IsNullOrEmpty(produto.Descricao))
Console.WriteLine("Não foi possivel adicionar o produto pois a descrição está vazio");
else if (produto.Preco == 0)
Console.WriteLine(“Não foi possível adicionar o produto pois o preço está vazio”);
else if (produto.Quantidade == 0)
Console.WriteLine("Não foi possível adicionar o produto pois a quantidade está vazia");
else
//salvar no banco de dados
Console.WriteLine("Produto cadastrado!");
Console.ReadKey();
}

Percebe-se, assim, que o método “Adicionar” da classe produto deveria somente

adicionar um produto, entretanto, ele vai além. Verificando-o, tem-se a evidente
impressão de um método de homologação e inserção ao mesmo tempo, portanto, infere-
se que ele tem mais de uma responsabilidade.
Todavia, em consonância com o princípio da responsabilidade única, foi possível ajustar
essa decodificação reduzindo o seu acoplamento. Por conseguinte, outra classe passou a
ser criada com a responsabilidade específica de implementar o método para inserir o
produto.

namespace CorrecaoS.SOLID
{
public class AdicionarProduto
{
public void Adicionar (Produto produto)
{
ValidarProduto validarProduto = new ValidarProduto();

var result = validarProduto.ValidarCampos (produto);

if(result.Count = 0)
Console.WriteLine("Produto salvo!");
else
{
Console.WriteLine("Não foi possivel adicionar o produto pois : \n");
foreach (var item in result)
{
Console.WriteLine(item.Mensagem);
}

}
Console.ReadKey();
}

Analisando a classe AdicionarProduto, observe que o método "Adicionar" não realiza

algum tipo de validação nos atributos do objeto produto, ao invés disso, seguindo a
ideia do princípio da responsabilidade única, uma nova classe precisa ser criada com
todas as validações necessárias para realizar o armazenamento consistente do produto.
Veja:

namespace CorrecaoS.SOLID
{
public class ValidarProduto
{
public List<MensagemErro> ValidarCampos (Produto produto)
{
List<MensagemErro> mensagensErro = new List<MensagemErro>();

if (produto.Id == 0)
mensagensErro.Add(new MensagemErro("O Id não pode ser nulo"));
if (String.IsNullOrEmpty(produto.Nome))
mensagensErro.Add(new MensagemErro("O nome não pode ser nulo"));
if (String.IsNullOrEmpty(produto.Descricao))
mensagensErro.Add(new MensagemErro("A descrição não pode ser nula"));
if (produto.Preco == 0)
mensagensErro.Add(new MensagemErro("O preço não pode ser nulo"));
if (produto.Quantidade == 0)
 mensagensErro.Add(new MensagemErro("A quantidade não pode ser nula"));

return mensagensErro;
}

Afirma-se que a classe "ValidarProduto" possui um método "ValidarCampos", que é

responsável por validar os atributos do produto e retornar mensagens de erro, ou seja,
para cada violação encontrada no objeto, uma mensagem autoexplicativa será
adicionado na saída. Cabe destacar que para acrescentar mensagens de erro à lista de
mensagens, foi necessário instanciar outra classe para permitir a inclusão de mensagens
de erro, veja:

namespace CorrecaoS.SOLID
{
public class MensagemErro
{
public string Mensagem{get; set; }

public MensagemErro(string Mensagem)

{
this.Mensagem = Mensagem;
}

Finalmente, foi possível notar a prática da efetivação do primeiro princípio SOLID. A

concretização do princípio S nos projetos não é descomplicada, exige uma elaboração
antecipada de quais classes serão cruciais ao aplicativo. Há de esclarecer a importância
de utilizá-las de forma descentralizada para que suas tarefas sejam bem separadas,
proporcionando um bom esboço das operações do projeto e, assim, aumentando o nível
do comportamento dos processos de negócio valorizando suas questões de desempenho,
bom entendimento, manutenibilidade e extensão.

4. Conclusão
É possível notar a partir do estudo conduzido que os princípios SOLID contribuem
enormemente para o processo de desenvolvimento de software. Esses princípios, assim
como a POO, são hoje predominantes no mercado, pois garantem a qualidade, robustez,
eficiência e maior confiabilidade do produto. Ao utilizar desses princípios, o
desenvolvedor de software poderá tornar seu processo mais compreensível, o que
auxilia em toda a extensão de seu trabalho.
5. References
RIBEIRO, Ester Andrade e TIOSSO, Fernando. Princípio da Responsabilidade Única
Aplicada ao Desenvolvimento de Aplicações. Revista Fatec. Disponível em:
https://revista.fatectq.edu.br/interfacetecnologica/article/view/625/341. Acesso em:
02/09/2022.