Práticas de Orientação a Objetos – Hipsters #129

E essa tal de orientação objetos? Código limpo? SOLID? Fácil de dar manutenção? E os design patterns? Domain Driven? Tem muita coisa relacionada a esse conceito e o episódio consegue passar por vários deles… mas não todos 🙂

Participantes:

Links:

Produção e conteúdo:

  • Alura Cursos online de Tecnologia
  • Caelum Ensino e Inovação

Edição e sonorização: Radiofobia Podcast e Multimídia

Leave a Reply

21 Comentários

  1. Lucas Palma Stabile

    Ótimo episódio! Tenho uma dúvida que não sei se aplica ao princípio de responsabilidade única: num projeto com parte back-end e front-end é ideal que se tenha verificações e validações em ambos os lados, se eu escolher utilizar algum enumerador para verificar algum valor no back-end, seria necessário tmb “repetir” esse enumerador no front-end? Já me encontrei nessas ocasiões e não sabia por onde seguir.
    Ótimo ano para vocês!

    • Roberta Arcoverde

      Temos alguns casos desses no nosso código também. Não sei se dá pra evitar a duplicação, mas aqui o que fazemos é torná-la automática ao invés de manual. Temos um scriptzinho em T4 (old but gold) que gera o código dos enumeradores que queremos definir também no front, em Typescript.

    • Opa, Lucas!

      Já participei de projetos em que a validação era apenas no front-end, mas era uma brecha muito grande em termos de segurança. É muito importante ter as validações no back-end, não é mesmo?

      Em aplicações mais antigas, em que o HTML era todo renderizado no servidor, as validações em JS no front seriam apenas uma pitada, pra melhorar o desempenho da aplicação.

      Agora, com SPA e frameworks JS mais modernos, a validação no JS passou a ser muito importante. Se você usa JS no back, com o Node, dá pra rodar o mesmo código pra validar no back e no front. É o que chamam Isomorphic JS. Já vi fazerem isso com o próprio Java no back, já que a JRE vem com um interpretador JS embutido (o Rhino, até o Java 7, e o Nashhorn, do Java 8 em diante).

      ——

      É interessante você ter mencionado o Princípio da Responsabilidade Única ao falar de validação.

      A princípio, validar seria uma responsabilidade e, portanto, a validação de uma entidade de negócio deveria estar separada em uma classe própria.

      Mas, lembrando do que o seu xará Lucas falou no podcast, a ideia seria focar em “atores” (técnicos ou de negócio) e na mudança provocada por esses atores. O Financeiro seria um ator. O RH seria outro ator. Código de Banco de Dados seria outro ator.

      Considerando isso, a validação poderia ser parte da própria classe que representa uma entidade de negócio, se não tivermos validações diferentes para diferentes atores.

      Agora, num projeto maior, pode ser que o RH valide de um jeito e o Financeiro de outro. Aí, vale uma classe separada.

      No fim das contas, o foco da Responsabilidade Única é nos motivos pra uma classe ser modificado.

      ——

      PS: desculpe pelo textão.

  2. Douglas Marques

    Acho que vale a pena ainda recomendar o ‘Orientação a Objetos e SOLID para Ninjas’, do Maurício Aniche. Baita livro da Casa do Código. Ouvi dizer que os prefácios são escritos por profissionais de primeira 😛

  3. Welyab Paula

    Em 2003 o Martin Fowler escreveu esse texto sobre “anemic domain models”, que trata daquelas classes que são burrinhas e servem apenas como armazém de dados, mas pouco conhecem, ou pouco fazem com as informações contidas. Segue o link: https://www.martinfowler.com/bliki/AnemicDomainModel.html

    Quando descobri esse conceito, o que mais me chamou atenção foi a maneira como eu sempre programei JPA, muito, muito anêmico. E acho que muito do que está na Internet ajuda nisso. Numa análise mais aprofundada, é possível sim usar JPA em um domínio consciente de sua própria lógica. Um domínio com classes mais OO capazes de trocar mengens com outras classes.

    Peguei sistemas com padrão MVC que a camada de view só montava a visão baseado nas regras de uma camada de controle. Os dados transitando entre essas camadas com a ajuda de classes demominadas modelo, depósito de dados, sem nenhuma lógica embutida em si. Desta forma, o que temos é um software procedural que pouco usa do poder da OO.

    Excelente episódio. Pena que para o formato do podcast, esse assunto é um pouco complicado de apenas falar. É um assunto para ser abordado mais com a mão na massa, ainda mais para quem está começando.

  4. Sebastião Relson Reis da Luz

    Eu vivi uma questão parecida aí q a Roberta falou sobre as interfaces, mas ao invés disso era o SQL, q tinha de ser “ANSI” pra mesma situação de migração de banco que nunca aconteceu até onde tenho notícia. Quando comecei lá foi em 2006.

  5. Parabéns pelo episodio, bem esclarecedor para você mandar para a aquele seu amigo da programação estruturada.

  6. Felipe Lambert

    Parabéns pelo podcast, olha não troquei o SGBD porém o IRepository já me salvou ao trocar de memory cache pra redis, e de atualização de versão de uma api com baixo impacto onde utilizei com o pattern Proxy para manter o comportamento da versão antiga.

  7. Queria saber se alguém tem a algum artigo ou livro com os padrões de projeto revisitados levando em conta os avanços das novas linguagens?

  8. Fernando Boaglio

    vou abrir um pull request no projeto do Spring e pedir para incluírem: @Scope("Solteirão")

  9. Juliano Soares

    Ei Paulo, um tema que eu ando pesquisando ultimamente e daria um bom ep seria a como a Lei Geral de Proteção de Dados afeta os devs. Ou então algo relacionado a legislação que os devs devem estar atentos.

    • Rafael Felipe

      Geralmente quem tem que ficar de olho não são os devs, geralmente quem gera demanda pros devs que tem que ficar de olho (advogados, contadores, etc…) é igual NF-e, SPED, e-social, etc…
      Em breve tem uma reforma tributária, vai gerar bastante trabalho pra gente.

      • Juliano Soares

        Eu estava pensando nos devs que quem alguma ideia e gostariam de fazer um protótipo ou naqueles projetos onde a equipe basicamente se resume a um designer e um ou dois devs. Coisas desse tipo. Por exemplo, hoje eu já prevejo possíveis problemas pra quem queira simplesmente criar um blog ou colocar no ar um landing page pra coletar leads.

  10. Diéffrei Quadros

    Também achei bem chato o livro do Eric Evans, aconselho a ler o livro do Vaughn Vernon (Implementando Domain-Driven Design)

    • Abraão Borges Neves

      Cara posso saber porque gostou mais deste livro, estou montando uma lib para estudos de DDD e sempre escuto em todos os lugares que o livro do Evans realmente é bem chato hahaha.

  11. mestihudson

    Muito bacana a discussão. No começo fiquei ansioso para saber se Uncle Bob iria entrar na conversa. E vi que ficou faltando coisa mas que já programam um novo encontro sobre o tema. Sendo assim sugiro entrar em pauta o livro “Elegant Objects” do Yegor Bugayenko (yegor256.com), e sua visão, no mínimo, peculiar sobre OOP.

    Parabéns pelo trabalho cada vez mas interessante.

  12. Renan Duarte

    Cade o PodCast das tendencias para 2019 e 2020 ? Previsões, especulações, falsas esperanças, etc… cade? cade?

Next ArticleChatbots e jornada do usuário - Hipsters #130