16 maio 2016

Há tempos venho debatendo aqui na redspark com o Guilherme Vargas, o fato dos desenvolvedores terem acostumado muito com as tecnologias e, consequentemente, acabam deixando de lado o verdadeiro conceito de Orientação a Objeto. Deixamos de pensar em primeiro lugar nas boas práticas e nos antigos princípios e voltamos a programar estruturalmente ou orientado ao framework. Nossos domains como um saco de getter e setter, totalmente anêmico, nossos controllers possuem um mapeamento para as requisições e muitas vezes já saem fazendo buscas ao banco, manipulação de estado de objeto, ou delegam para algum método da camada Service que possui mil e uma responsabilidades. Não digo que é culpa dos desenvolvedores, já percebi que aprenderam a desenvolver desta forma e ficaram acostumados, talvez por serem novos na área e não conhecerem a fundo o OO Design ou por não terem tido influência, pois a idéia de princípios SOLID já é bem antiga e acaba caindo no esquecimento.

Se você está pensando “Por que eu preciso me preocupar com isso?” ou “Isso é besteira, eu programo orientado a objetos SIM!”, me diga uma coisa, quantas vezes você já precisou modificar, seja adicionar, excluir ou alterar, um código de outra pessoa, ou até mesmo seu, e sentiu uma dificuldade de entender o que estava se passando ali ou modificou e afetou outras partes do sistema que você nem sabia que existia? Então, isso é porque os códigos não foram elaborados de forma coesa e provavelmente estão muito acoplados, cheios de ifs e linhas desnecessárias, deixando bad smells por todo lado e que dá medo de mexer. Se o código se encontra desta forma, com certeza ele não foi desenvolvido respeitando o OO Design.
CTA-ebook-transformação-digital

Analisando isso, tivemos a ideia de criar uma série de posts explicando os princípios SOLID e alguns dos patterns mais utilizados atualmente, voltados a Java, mas não só voltado ao java como em conjunto ao Spring Framework.

OS PRINCÍPIOS:

Os princípios SOLID, os patterns e as boas práticas não ajudam só a evitar este tipo de coisa, com seu código coeso e desacoplado, fica mais fácil de ser testado e modificado, aumentado a qualidade do software. Fazendo com que não seja um sacrifício adicionar uma feature ou fazer uma modificação que o cliente pede.
Nesse primeiro post vou lhes apresentar os Princípios SOLID, que pra quem não conhece, são:

– Princípio da Responsabilidade Única (SRP);
– Princípio Aberto Fechado (OCP);
– Princípio de Substituição de Liskov (LSP);
– Princípio da Segregação de Interfaces (ISP);
– Princípio da Injeção de Dependência (DIP);

Pra não ficar tão extenso e cansativo, não irei explica-los neste post, só deixarei essa introdução sobre os benefícios dos princípios do Design Orientado a Objeto. No próximo post começarei com o SRP, o primeiro do acrônomo, e a cada novo post vou linkando com o mesmo acima.

Gabriel Suaki – Software Engineer at redspark.
GitHub: GSuaki
Twitter: @gsuaki

Gabriel Suaki
About Gabriel Suaki

Software Engineer at redspark Gabriel Suaki - Software Engineer at redspark.

Comments

  • Anderson Ferreira da Silva
    maio 18, 2016 Responder

    Genial, gostei do assunto. Realmente todas as empresas que trabalhei desenvolvem assim.

    • Gabriel Suaki
      Gabriel Suaki
      maio 18, 2016 Responder

      Valeu Anderson!

Leave a Comment