https://media.blubrry.com/hipsterstech/content.blubrry.com/hipsterstech/hipsters_129_orientacao_a_objeto.mp3Podcast: Play in new window | Download | Embed RSS | More Compartilhar Assinar Práticas de Orientação a Objetos – Hipsters #129 01/01/2019 / programação / 21 Comentários 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: Paulo Silveira, o host que está feliz por um episódio que ainda entende do assunto Roberta Arcoverde, a cohost que manja de verdade do assunto Lucas Felix, instrutor e desenvolvedor na Caelum Alexandre Aquiles, da Caelum Brasília, um dos autores do curso de SOLID Links: O Universo da Programação, livro do William Livro Design Patterns Como não aprender orientação a objetos: herança Como não aprender orientação a objetos: getters e setters Princípios SOLID Postagem de 1995 no grupo Usenet comp.object em que Uncle Bob menciona a maioria das ideias do SOLID “The Art of Enbugging“, de 2003, dos Pragmatic Programmers (Andy Hunt e Dave Thomas) Carreiras e formações da Alura Curso de Práticas de Design e Arquitetura de Código na Caelum 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 Relacionado
Lucas Palma Stabile - 0 Ó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! Responder
Roberta Arcoverde - 0 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. Responder
Alexandre Aquiles - 0 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. Responder
Douglas Marques - 0 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 😛 Responder
Alexandre Aquiles - 0 Ótima dica, Douglas. O livro do Aniche é uma das principais referências do novo curso de Práticas de Design e Arquitetura de código para aplicações Java da Caelum. Fica o link para quem tiver interesse: https://www.casadocodigo.com.br/products/livro-oo-solid Responder
Welyab Paula - 0 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. Responder
Sebastião Relson Reis da Luz - 0 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. Responder
Cleber C. - 0 Parabéns pelo episodio, bem esclarecedor para você mandar para a aquele seu amigo da programação estruturada. Responder
Felipe Lambert - 0 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. Responder
Tiago Faustino - 0 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? Responder
Fernando Boaglio - 0 vou abrir um pull request no projeto do Spring e pedir para incluírem: @Scope("Solteirão") Responder
Juliano Soares - 0 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. Responder
Rafael Felipe - 0 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. Responder
Juliano Soares - 0 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. Responder
Diéffrei Quadros - 0 Também achei bem chato o livro do Eric Evans, aconselho a ler o livro do Vaughn Vernon (Implementando Domain-Driven Design) Responder
Abraão Borges Neves - 0 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. Responder
Diéffrei Quadros - 0 Achei melhor a didática do livro do Vaughn Vernon. Comprei dois livros dele: – Domain-Driven Design Distilled (Resumo do resumo) – Implementing Domain-Driven Design E ainda você tem o repo p terirar alguma dúvida que talvez não tenha ficado bem clara no livro. (https://github.com/VaughnVernon/IDDD_Samples) Responder
mestihudson - 0 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. Responder
Renan Duarte - 0 Cade o PodCast das tendencias para 2019 e 2020 ? Previsões, especulações, falsas esperanças, etc… cade? cade? Responder
