SOLID é um acrônimo mnemônico criado por Michael Feathers e popularizados pelo Uncle Bob, Robert C. Martin, que relaciona a cada letra um tópico de boas práticas de programação. A prática destes princípios SOLID visa deixar o projeto mais coeso, reaproveitável e torna a sua manutenção mais fácil.
Este artigo abordará as duas primeiras letras – ou melhor, as duas primeiras práticas –, o Single responsibility principle (princípio da responsabilidade única) e o Open/closed principle (principio aberto/fechado).
<figure id="attachment_432" aria-describedby="caption-attachment-432" style="width: 514px" class="wp-caption aligncenter"><a class="lightbox" href="https://dtidigital.com.br/wp-content/uploads/2015/10/solid.png"><img fetchpriority="high" decoding="async" class="wp-image-432 size-full" title="Princípios SOLID" src="https://dtidigital.com.br/wp-content/uploads/2015/10/solid.png" alt="solid" width="514" height="498" /></a><figcaption id="caption-attachment-432" class="wp-caption-text">Figura 1 &#8211; Princípios de um código orientado a objetos sustentável</figcaption></figure>
O <a style="color: #ff6600;" href="https://drive.google.com/file/d/0ByOwmqah_nuGNHEtcU5OekdDMkk/view?pli=1">princípio da responsabilidade única</a> tem como regra que uma classe deve possuir uma, e apenas uma, responsabilidade. Pode-se traduzir isso em “uma classe deve ter apenas um motivo para mudar”.
<div id="toc_container" role="navigation" aria-label="Table of Contents" data-nosnippet class="toc_white no_bullets toc_numbered toc_title_center">Sumário<ul class="toc_list"><li><a href="#Por-que-uma-classe-deve-ter-apenas-uma-responsabilidade">1. Por que uma classe deve ter apenas uma responsabilidade?</a></li><li><a href="#Como-deveria-ser">2. Como deveria ser?</a></li><li><a href="#Qual-a-importancia-deste-principio">3. Qual a importância deste princípio?</a></li><li><a href="#E-qual-e-o-problema-de-um-IF-a-mais-na-classe">4. E qual é o problema de um IF a mais na classe?</a></li><li><a href="#Entao-qual-e-a-solucao">5. Então qual é a solução?</a><ul><li><ul><li><a href="#Tem-alguma-duvida-sobre-os-principios-SOLID-Entre-em-contato-com-a-gente">5.0.1. Tem alguma dúvida sobre os princípios SOLID? Entre em contato com a gente.</a><ul><li><a href="#Por-Victor-Castro">5.0.1.1. Por: Victor Castro.</a></li><li><a href="#Revisao-Jessica-Saliba">5.0.1.2. Revisão: Jéssica Saliba.</a></li></ul></li></ul></li></ul></li></ul></div>
<h2 style="text-align: justify;">Por que uma classe deve ter apenas uma responsabilidade?</h2>
A reposta é simples: quanto maior o número de responsabilidades, maiores as chances de modificação dessa classe no futuro e maiores as chances de inserção de bugs que atrapalharão a classe por inteiro.
Imaginemos o seguinte exemplo:
<pre lang="csharp">#region Código 1
public class Cozinheiro
{
	public void fazerPrato(object prato) 
	{
 // código para a realização de pratos
 }
 
 public double valorDoPrato(object prato) 
	{
 // código para o calculo do valor do prato
 }
	
 public void recolherPratos() 
	{
 // código para recolher os pratos
 }
}
#endregion

</pre>
Esta classe é responsável por preparar o prato e calcular o valor do prato e recolher os pratos. Esses ‘es’ indicam que a nossa classe possui mais de uma responsabilidade, e assim, mais de um motivo para ser modificada. Caso desejássemos modificar a maneira com que os pratos são recolhidos, teríamos que modificar a nossa classe Cozinheiro. Caso esta modificação gerasse algum bug, não apenas a retirada dos pratos, mas sim todas as funcionalidades da classe poderiam estar comprometidas. A classe Cozinheiro deixaria de preparar a comida devido um problema com a retirada de pratos.
<h2 style="text-align: justify;">Como deveria ser?</h2>
A pergunta aqui é: qual a responsabilidade da classe Cozinheiro? Preparar o prato! Perceba que não importam a quantidade de métodos necessários para tal. A ‘responsabilidade única’ está ligada à função da classe, e não à maneira que esta função é implementada. Veja como ficaria a refatoração do código:
&nbsp;
<pre lang="csharp">#region Código 2
public class Cozinheiro
{
	public void fazerPrato(object prato) 
	{
 // código para a realização de pratos
 }
}

public class Caixa
{	
 public double valorDoPrato(object prato) 
	{
 // código para o calculo do valor do prato
 }
}
	
public class Garcon
{	
 public void recolherPratos() 
	{
 // código para recolher os pratos
 }
}
#endregion

</pre>
A classe Cozinheiro agora possui apenas uma única responsabilidade: preparar o prato. O único motivo para alterar essa classe é caso a forma de preparar o prato seja modificada, reduzindo assim a complexidade, facilitando a legibilidade e reduzindo o acoplamento.
<figure id="attachment_433" aria-describedby="caption-attachment-433" style="width: 500px" class="wp-caption aligncenter"><a class="lightbox" href="https://dtidigital.com.br/wp-content/uploads/2015/10/solid2.png"><img decoding="async" class="wp-image-433 size-full" title="Princípios SOLID" src="https://dtidigital.com.br/wp-content/uploads/2015/10/solid2.png" alt="Figura 2 - &quot;Só porque você pode, não significa que você deva&quot;" width="500" height="367" /></a><figcaption id="caption-attachment-433" class="wp-caption-text">Figura 2 &#8211; &#8220;Só porque você pode, não significa que você deva&#8221;</figcaption></figure>
O <a style="color: #ff6600;" href="https://drive.google.com/a/cleancoder.com/file/d/0BwhCYaYDn8EgN2M5MTkwM2EtNWFkZC00ZTI3LWFjZTUtNTFhZGZiYmUzODc1/view?pli=1">princípio aberto/fechado</a> diz que as entidades de software (classes, módulos, funções, etc.) devem estar abertas para extensão, mas fechadas para modificação, ou seja, deve ser possível estender o comportamento de uma classe, mas não a modificar.
<h2 style="text-align: justify;">Qual a importância deste princípio?</h2>
A extensibilidade! É comum a manutenção de códigos. Você deve, então, lidar com as classes já criadas e, possivelmente, adicionar ou remover funcionalidades. Para uma classe ‘não-extensível’, a adição ou remoção de funcionalidades implica na modificação da classe por si só. Ao fazer tal mudança, você estará propenso a fazer com que outras partes do seu código não funcionem mais.
Utilizando a nossa classe Cozinheiro, poderíamos implementar a função de preparar pratos da seguinte forma:
<pre lang="csharp">#region Código 3
public class Cozinheiro
{
	public void fazerPrato(object prato) 
	{
		if (prato is Omelete)
		{
		// código para a realização de um omelete
		}
		
		if (prato is Macarrao)
		{
		// código para a realização de um macarrao
		}
		
		if (prato is FrangoAssado)
		{
		// código para a realização de um frango assado
		}
 }
}

public class Omelete
{
// propriedades do omelete
}
public class Macarrao
{
// propriedades do macarrão
}
public class FrangoAssado
{
// propriedades do frango assado
}

#endregion
</pre>
Aparentemente, nenhum problema. Mas e se quiséssemos implementar um prato novo? Teríamos que modificar a classe Cozinheiro.
<h2 style="text-align: justify;">E qual é o problema de um IF a mais na classe?</h2>
Ao adicionar outro IF de validação, além de termos que substituir a classe na publicação da nova versão, estaremos correndo o risco de introduzir bugs em uma classe que já estava funcionando.
Assim, para cada prato novo, seriam necessárias novas alterações na classe Cozinheiro, e para cada uma dessas alterações, teríamos que nos assegurar que as funcionalidades anteriores continuassem funcionando e que as novas funcionalidades não interferissem nas antigas.
<h2 style="text-align: justify;">Então qual é a solução?</h2>
A utilização da abstração. A classe pai deve possuir o método exigido (que no nosso caso é o fazerPrato), enquanto os filhos dessa classe devem apenas implementar a forma com que este método será executado. Veja como este princípio seria implementado no exemplo anterior:
<pre lang="csharp">#region Código 4
public class Cozinheiro
{
	public void fazerPrato(Prato prato) 
	{
		prato.Fazer();
 }
}

public abstract class Prato
{
	public abstract void Fazer();
}

public class Omelete : Prato
{
// propriedades do omelete

	public override void Fazer()
	{
	// código para a realização de um omelete
	}
}

public class Macarrao : Prato
{
// propriedades do macarrao

	public override void Fazer()
	{
	// código para a realização de um macarrao
	}
}

public class FrangoAssado : Prato
{
// propriedades do frango assado

	public override void Fazer()
	{
	// código para a realização de um frango assado
	}
}
#endregion

</pre>
Possuímos agora uma abstração bem definida, onde todas as extensões implementam suas próprias regras de negócio sem necessidade de modificar uma funcionalidade devido a remoção, mudança ou inclusão de outra.
Dessa forma a nossa nova classe Cozinheiro está aberta para extensão pois podemos incluir tantos pratos quanto desejarmos, mas está fechada para modificação pois podemos fazer isso sem ter que alterar a classe. Assim, além da independência entre as extensões, o código fica mais claro e a aplicação de testes de unidades fica mais fácil e coesa.
Observe assim que aplicando apenas dois princípios do SOLID em conjunto, aumenta-se bastante as chances de que o sistema criado seja mais claro e simples de estender.
<h4 style="text-align: justify;">Tem alguma dúvida sobre os princípios SOLID? Entre em <a style="color: #ff6600;" href="http://www.dtisistemas.com.br/#contato" target="_blank" rel="noopener">contato</a> com a gente.</h4>
<h5 style="text-align: justify;">Por: Victor Castro.</h5>
<h5 style="text-align: justify;">Revisão: Jéssica Saliba.</h5>

Princípios SOLID: responsabilidade única e aberto/fechado.

Desbloqueie o futuro do seu negócio

Mais conteúdos como esse

Travessa Dona Zilda, 125, sala 203, São Gonçalo – Pelotas, RS. CEP: 96075-166

14841 Dallas Parkway, 8th Floor Addison, TX 75254

R. Levindo Lopes, 357, 5º e 12º Andar – Savassi, Belo Horizonte MG, 30112-010