Em termos gerais, todas as linguagens de programação podem ser classificadas em dois paradigmas:  Programação     - Segue a sequência de instruções que são executadas linha por linha. imperativa / orientada a objetos      funcional - Não é sequencial, mas se preocupa mais com o objetivo do programa. Todo o programa é como uma função que possui subfunções, cada uma executando uma determinada tarefa. Programação declarativa/  Como desenvolvedor júnior, estou percebendo da maneira mais difícil (leia-se: eu estava olhando nervosamente para 1000 linhas de código) que não se trata apenas de escrever código funcional, mas também de código semanticamente fácil e flexível.  Embora existam várias práticas recomendadas para escrever código limpo em ambos os paradigmas, falarei sobre os princípios de design SOLID relativos ao paradigma de programação orientado a objetos.  O que é SÓLIDO?  S - Responsabilidade Única  O—Princípio Aberto-Fechado  L — Princípio da Substituição de Liskov  I — Segregação de interface  D - Inversão de Dependência  A principal razão para qualquer dificuldade em entender esses conceitos não é porque suas profundidades técnicas são insondáveis, mas porque são diretrizes abstratas que são generalizadas para escrever código limpo na programação orientada a objetos. Vejamos alguns diagramas de classe de alto nível para esclarecer esses conceitos.  Estes não são diagramas de classe precisos, mas são esquemas básicos para ajudar a entender quais métodos estão presentes em uma classe.  Vamos considerar um exemplo de café ao longo do artigo.  Princípio da Responsabilidade  Única  Uma classe deve ter apenas um motivo para mudar  Considere esta classe que lida com pedidos online recebidos pelo café.     Essa única classe é responsável por várias funções. E se você tiver que adicionar outros métodos de pagamento? E se você tiver várias maneiras de enviar a confirmação? Alterar a lógica de pagamento na classe responsável pelo processamento dos pedidos não é um projeto muito bom. Isso leva a um código altamente não flexível. O que há de errado com isso?  Uma maneira melhor seria separar essas funcionalidades específicas em classes concretas e chamar uma instância delas, conforme mostrado na ilustração abaixo.    Princípio Aberto-Fechado  As entidades devem estar abertas para extensão, mas fechadas para modificação.  No café, você deve escolher os condimentos para o seu café em uma lista de opções e há uma aula que trata disso.   O café decidiu adicionar um novo condimento, a manteiga. Observe como o preço vai mudar de acordo com o condimento selecionado e a lógica de cálculo do preço está na classe Café. Não apenas temos que adicionar uma nova classe de condimento a cada vez, o que cria possíveis alterações de código na classe principal, mas também lidar com a lógica de maneira diferente a cada vez.  Uma maneira melhor seria criar uma interface de condimentos que possa, por sua vez, ter classes filhas que sobrescrevam seus métodos. E a classe principal pode apenas usar a interface de condimentos para passar os parâmetros e obter a quantidade e o preço de cada pedido.    Isso tem duas vantagens:  1. Você pode alterar dinamicamente seu pedido para ter diferentes ou até vários condimentos (café com mocha e chocolate soa divino).  2. A classe Condiments terá um relacionamento com a classe Coffee, em vez de is-a. Portanto, seu café pode ter um tipo de café mocha/manteiga/leite em vez de seu café é um tipo de café mocha/manteiga/leite.  Princípio da Substituição de Liskov  Cada subclasse ou classe derivada deve ser substituível por sua classe base ou pai.  Isso significa que a subclasse deve ser capaz de substituir diretamente a classe pai; deve ter a mesma funcionalidade. Achei difícil de entender porque soa como uma fórmula matemática complexa. Mas vou tentar deixar claro neste artigo.  Considere a equipe do café. Existem baristas, gerentes e servidores. Todos eles têm funcionalidade semelhante.  Portanto, podemos criar uma classe Staff base com name, position, getName, getPostion, takeOrder(), serve().  Cada uma das classes concretas, Garçom, Barista e Gerente pode derivar disso e substituir os mesmos métodos para implementá-los conforme necessário para o cargo.   Neste exemplo,   é usado para garantir que qualquer classe derivada de Staff possa ser usada de forma intercambiável com a classe base de Staff sem afetar a correção do código. o Princípio de Substituição de Liskov (LSP)  Por exemplo, a classe Waiter estende a classe Staff e substitui os métodos takeOrder e serveOrder para incluir funcionalidade adicional específica para a função de um garçom. No entanto, mais importante, apesar das diferenças de funcionalidade, qualquer código que espera um objeto da classe Staff também pode funcionar corretamente com um objeto da classe Waiter.  Vejamos um exemplo para entender isso       staff.takeOrder(); staff.serveOrder(); } }                            } } public   class   Cafe   {      public   void   serveCustomer (Staff staff)   { public   class   Main   {      public   static   void   main (String[] args)   {  Cafe cafe = new  Cafe();  Staff staff1 = new  Staff( "John" , "Staff" );  Waiter waiter1 = new  Waiter( "Jane" );  restaurant.serveCustomer(staff1); // Works correctly with Staff object 
  restaurant.serveCustomer(waiter1); // Works correctly with Waiter object 
  Aqui o método serveCustomer() na classe Cafe, pega um objeto Staff como parâmetro. O método serveCustomer() chama os métodos takeOrder() e serveOrder() do objeto Staff para atender o cliente.  Na classe Main, criamos um objeto Staff e um objeto Waiter. Em seguida, chamamos o método serveCustomer() da classe Cafe duas vezes - uma vez com o objeto Staff e outra com o objeto Waiter.  Como a classe Waiter é derivada da classe Staff, qualquer código que espera um objeto da classe Staff também pode funcionar corretamente com um objeto da classe Waiter. Nesse caso, o método serveCustomer() da classe Cafe funciona corretamente com os objetos Staff e Waiter, mesmo que o objeto Waiter tenha funcionalidade adicional específica para a função de um garçom.   Segregação de interface  As classes não devem ser forçadas a depender de métodos que não usam.  Portanto, existe esta máquina de venda automática muito versátil no café que pode servir café, chá, lanches e refrigerantes.   O que está errado com isso? Nada tecnicamente. Se você tiver que implementar a interface para qualquer uma das funções, como servir café, também precisará implementar outros métodos para chá, refrigerante e lanches. Isso é desnecessário e essas funções não estão relacionadas entre si. Cada uma dessas funções tem muito menos   entre elas. coesão    É um fator que determina quão fortemente os métodos em uma interface se relacionam entre si. O que é coesão?  E no caso da máquina de venda automática, os métodos dificilmente são interdependentes. Podemos segregar os métodos, pois eles têm coesão muito baixa.   Agora, qualquer interface que se destina a implementar uma coisa, deve implementar apenas takeMoney() que é comum para todas as funções. Isso separa as funções não relacionadas em uma interface, evitando assim a implementação forçada de funções não relacionadas em uma interface.  Inversão de Dependência  Módulos de alto nível não devem depender de módulos de baixo nível. Detalhes devem depender de abstrações.   Considere o ar condicionado (resfriador) no café. E se você for como eu, está sempre congelando lá dentro. Vejamos o controle remoto e as classes AC.   Aqui, remoteControl é o módulo de alto nível que depende de AC, o componente de baixo nível. Se eu conseguir um voto, também gostaria de um aquecedor :P Então, para ter uma regulação genérica de temperatura, em vez de um refrigerador, vamos desacoplar o controle remoto e o controle de temperatura. Mas a classe remoteControl está fortemente acoplada com AC, que é uma implementação concreta. Para desacoplar a dependência, podemos criar uma interface que tenha funções apenas de aumentarTemp() e diminuirTemp() dentro de um intervalo de, digamos, 45-65 F.   Considerações Finais  Como você pode ver, os módulos de alto e baixo nível dependem de uma interface que abstrai a funcionalidade de aumentar ou diminuir a temperatura.  A classe de concreto, AC, implementa os métodos com a faixa de temperatura aplicável.  Agora provavelmente posso obter o aquecedor que desejo, implementando diferentes faixas de temperatura em uma classe de concreto diferente chamada aquecedor.  O módulo de alto nível, remoteControl, só precisa se preocupar em chamar o método correto durante o tempo de execução.

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Read My Stories

Este áudio é produzido no idioma original da história!

Como manter seu código SÓLIDO

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Telegram: a ponte da Crypto Island para o continente

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Telegram: a ponte da Crypto Island para o continente

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps