Post já nasce datado, mas só faz sentido para agora mesmo. Passei uns 10 anos da minha vida programando na linguagem Java e nos últimos 3 anos eu peguei poucos projetos, mas o que me impressiona nesses poucos projetos é que as coisas não mudam, inclusive a tara por patterns desnecessários e antipatterns.
Comecemos por Nomenclatura
Se voce chama sua classes de WhateverController, WhateverService e ou WhateverDAO, voce está usando notação hungara desnecessária e complicando a modelagem do seu negócio. Se o seu framework te obriga a nomear as classes com sufixos ou prefixos, ele está errado e é melhor procurar uma solução.
Se voce chama classes como WhateverModel ou WhateverEntity aí voce está estragando a amizade, se mate.
Se voce tem uma classe chamada Whatever e tem propriedades como nameWhatever, leia urgente Clean Code.
BOLOVO
As pessoas criavam entidades chamadas WhateverManager por não saberem orientação a objetos, se existe isso no seu projeto na maioria das vezes não tem muito o que fazer, mude de emprego ou de projeto. Mas… se for corajoso comece a refatorar isso guiado por testes, o livro “Growing Object-Oriented Software, Guided by Tests” vai te ajudar bastante. O Paulo Silveira e o Phillip Calçado nomearam esse anti-pattern de BOLOVO.
DAO
DAO é o pattern inútil quando falamos de negócios, principalmente CRUD. A não ser que você esteja codando Framework ou comittando em projetos como o Hibernate, voce não precisa escrever DAO. Voce usa Hibernate, a Session é seu DAO.
Se voce precisa de uma entidade para agrupar alguma lógica de ORM mais complexa no seu negócio – como algumas transações com rollback lógicos, uma alternativa é Repository. Mas por favor, leia o artigo do Phillip primeiro e não faça WhateverRepository. Não há problema nenhum voce ter Criteria dentro de um controller por exemplo, afinal isso é um pattern bem estabelecido e o mapeamento um-pra-um com outra entidade só vai complicar e não traz ganho algum.
Só uma dica aproveitando o tema ORM, o Hibernate trabalha e sempre trabalhou com convenções usando anotações, então não precisa mapear tudo. Basta um @Entity na maioria das vezes. Nos relacionamentos observe se ele já não mapeia tranquilo apenas com o @ManyToOne e diminua o ruído.
Em termos de Patterns, por mais caduco que já esteja, o PoEAA do Fowler ainda reina.
Interface e Implementação
Existe uma boa prática como guia que é desenvolver orientado a interface, só que isso não é lei e deve ser usado o bom senso como sempre. A maioria dos desenvolvedores criam a Interface Whatever e uma – e apenas uma – implementação WhateverImpl. Isso é desnecessário e muita gente nem sabe que o Spring sempre funcionou injetar em classes concretas e não apenas em Interface. Deixe a Interface gritar na sua cara para refatorar.
Service e Domain Driven Design
Aqui que mora o perigo, sempre quando eu vejo WhateverService a implementação dessa classe é o mesmo código do antigo WhateverManager. Depois que Domain Driven Design fez sucesso todo mundo finje que modela o domínio.
As classes do seu domínio devem e podem ter métodos de negócios, se ela apenas tem propriedades é sinal do BOLOVO e representa uma tabela do banco de dados vitaminada. Um Service não é a parte de negócios do seu domain, a grosso modo de explicar o código dele explodiu na sua cara por manipular duas ou mais entidades e não ser responsabilidade de nenhuma delas.
ANUNCIO EM LETRAS GARRAFAIS
Cuidado com os livros que eu indiquei, quando foram escritos o Hibernate e o Spring estavam nascendo ou ainda não tinham nascidos, portanto leia com moderação. Várias coisas já forma implementadas pelos Frameworks e não vá fazer uma roda por cima de outra roda.
TL;DR
Cuidado com o código que voce escreve, faça-o guiado por testes, leia bons livros de Orientação a objetos e Patterns. Não escreva código igual aos outros porque é assim que todo mundo faz.
Typically chemist’s shop can sale to you with discreet treatments for various soundness problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about “viagra manufacturer coupon“. Maybe “viagra discount coupons” is a extremely complicated problem. Matters, like “coupons for viagra“, are united numerous types of health problems. If you need to take recipe medications, ask your pharmacist to check your testosterone levels before. Sometimes the treatment options may include erectile dysfunction remedies or a suction device that helps get an hard-on. Keep in mind web-site which is ready to sell erectile dysfunction drugs like Viagra without a recipe is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies.
A maior dificuldade está no começo. Os livros e tutorias que mostram código usam essas convenções e seguem essas práticas, talvez pra facilitar o entendimento. Ai quando começa errado e não encontra um arquiteto* para orientar e dar essas dicas, acaba crescendo errado.
*Arquiteto == Dev. Foda
@Marcos, como eu escrevi no “ANUNCIO EM LETRAS GARRAFAIS” 🙂
Esses livros quando foram escritos ainda não existiam esses Frameworks ou ainda eram muito incipientes/desconhecidos.
Antes tínhamos que montar os DAOs e outras coisas na mão mesmo.
O lance da nomenclatura foi amadurecimento, o Yoshima tem um grande mérito nisso, dá uma lida com bastante calma no post do Phillip http://philcalcado.com/2010/12/23/how-to-write-a-repository/
Frameworks MVC vieram de certo modo para nos ajudar com a parte C(ontroller) da coisa toda. Normalmente, eles adotam nomenclaturas para suas classes de controle. ex: Struts:Action, Vraptor:Controller etc. O que tenho em mente é que os controladores são uma camada do nosso negócio (da t.i, o meio) que se comunica com a camada do negócio final (o dominio da aplicação mesmo, o fim para qual ela foi produzida).
Eu gosto de padrões de nomenclaturas para classes controladoras. Elas se tornam facilmente identificadas quando falando do nosso negócio. Qual opção você apresenta para essa camada em especial?
No mais, quando se trata camada Model (Service, Repository, VO, BO etc.), concordo com você em todos os pontos.
Sobre o desenvolvimento orientado à interfaces, mesmo com o Effective Java tendo um item destinado a esse assunto, comparando o com a herança, creio que o sentido da frase seja um pouco mais abstrato. O desenvolvimento deve ser voltado para interface pública das suas classes, ou seja, as operações que ela expõe. Isso não se aplica apenas para uma linguagem.
Ótimo post, valeu pelas dicas.
Sobre a parte da ‘notação húngara’ :Qual seria a melhor opção pra não fazer XXXController,XXXService etc?
@Arthur Moura Carvalho
Controller não são camadas, são responsabilidades de objetos que tanto podem estar na camada de apresentação quanto na camada de negócios.
E o VRaptor não obriga a classe ter sufixo controller, quem define que é controller é a anotação 😉
@Rafael Roque
A melhor opção para não usar sufixo é não usar sufixo 🙂
Não precisa nomear com sufixo.
Sobre o que aprendi de MVC, a separação era em camadas. Mas posso ter entendido errado ou o conceito pode estar mudando etc. ok.
A dúvida agora ficou para uma nomenclatura de classes de controle legal (não que a nomenclatura seja obrigatória, claro). No artigo indicado do Philip, uma opção para um repositório seria [All|Todos]Entidade.
Como eu nomearia uma controller de forma legal para um CRUD de clientes, por exemplo?
Opa! Só pra dar os devidos créditos, quem criou esse nome BOLOVO foi o Phillip apenas. Eu estava dando uma palestra com ele que popularizou o termo, mas, pra variar, ele que inventou.
@cmilfont,
Concordo em parte. 🙂
Vamos por partes então:
Nomenclatura
Concordo que notação húngara não é legal, mas basicamente na modelagem de classes de domínio. Os nomes
das classes de domínio não pertencem ao programador. Devem refletir o vocabulário usado nas reuniões e
principalmente com o cliente. Mas não vejo mal quando usado em classes com responsabilidades
relacionadas a infraestrutura. Acho até que evita ruído na comunicação entre os desenvolvedores, nesses casos.
Além disso, é o tipo de código que o cliente normalmente nem fica sabendo que existe. Você não fala de
controllers numa reunião com cliente.
Concordo com o BOLOVO e nem preciso explicar.
Sobre DAOS, concordo em parte.
As alternativas são fazer sempre testes de integração (controllers), indo até o banco, ou mockando
sessions e criterias, se você usa hibernate, o que é muito provável.
Nenhuma das opções me parecem razoáveis.
Daí pra frente concordo com tudo.
Gostei do post.
Concordo com hvitorino. Creio que a nomenclatura deve refletir o que for mais “legível” para a equipe.
Bom post!
t: @cengenharia
Acho quem quem precisa mudar são os profissional Java…..kkkkkkk
Padrões são importante, e o mais importante ainda é resolver problema de boas maneiras. Claro, adequando o código para facilitar tanto leitura quanto manutenção será sempre válido, mas esse preciosismo para definir nomenclatura, particularmente para mim, é pura bobagem!
Continuo escrevendo DAO, Manager, Service. Os códigos são limpos, e isso não é uma consideração única: outros desenvolvedores alteram e identificam pontos no código, quando há erros, de maneira rápida, além de terem facilidade para efetuar a correção. A [boa] experiência, nesses casos, será na maioria da vezes o maior aliado do desenvolvedor para escrever códigos limpos e decentes, do quê ter essa preocupação toda para se definir nomes de classes ou quaisquer outros elementos.
@Felipe, o post não é sobre nomear coisas simplesmente e sim como o nome indica más práticas ou código desnecessário, consequência e não causa.
A causa é uma má compreensão dos patterns e dos paradigmas além de fazer as coisas porque todo mundo faz.
@cmilfont, entendo sua colocação, assim como havia entendido sobre o quê o texto tratava. E parafraseando à você mesmo, […além de fazer as coisas porque todo mundo faz…], evitar o uso dos velhos sufixos para evitar essas tais “más práticas, não seria mais uma [nova] vertente para não ter essa falta de compreensão!?
Hoje, de acordo com o contexto, escrever utilizando o sufixo DAO, pode ser considerado inútil, enquanto que Repository, pode ser considerado a melhor forma. Ou seja, nomenclaturas diferentes para representar, praticamente, coisas similares.
A discussão é válida e não estou fazendo crítica ao seu texto e comentário; e sou à favor de patterns.
Tem gente usando ainda servidor de aplicação para criar uma aplicação de um botão, mudar a cor de uma lâmpada, em pleno 2012. E que considera o Java EE como uma arquitetura pronta, que voce nem precisa pensar no que vai fazer se a aplicação não for muito difícil. É o cúmulo do enlatado, da arquitetura de caixinha, que a galera bloga há mais de 8 anos contra. fazer o que?
Bom artigo Milfont.
Pingback: Workshop Agile - Blog de desenvolvimento da Milfont Consulting, Client e Server-side
Eu gosto da nomenclatura com Service, Controller etc… menos Entity é claro. Acho que isso não afeta em nada a aplicação, pelo contrário ajuda no entendimento rápido e comunicação entre os desenvolvedores. As dicas do post são boas e válidas, mas essa da nomenclatura foi frescura.
@Thiago
Nomenclatura é um indicativo de que voce repete o que todo mundo faz sem pensar muito no seu domain, simplesmente vai jogando coisas no projeto.
Pode até ser que não prejudique em nada, mas já demonstra que você não teve grande zelo na sua modelagem, voce chama de frescura e eu chamo de “mais um código que terei que me ferrar para entender”.
Na prática essa de que “ajuda o entendimento rápido e comunicação” não funciona na prática, quando voce faz o que todo mundo faz porque aprendi assim é natural pegar Transaction Script em todo o código.
Enfim, meus anos de experiência já me ensinaram que a nomenclatura me ajuda a identificar de cara o knowhow de quem escreveu aquele código.
Afinal o livro Clean Code foca muito na nomenclatura, mas vai ver o Clean Code é frescura também.
Olá, cmilfont!!
Li todos os comments e até agora não obtive a resposta: porque não usar sufixos?
“… é um indicativo de que voce repete o que todo mundo faz sem pensar muito no seu domain, simplesmente vai jogando coisas no projeto.”
“… “mais um código que terei que me ferrar para entender”.”
Porque? Qual é o problema real de empregar sufixos? Porque realmente não devemos utilizar sufixos?
Respostas como: porque indica que você faz o que os outros fazem é meio “non-technical” não acha?
Olá Ricardo Russo,
No mindset de DDD, usar pre ou sufixos indica que voce não está modelando seu domain de forma clara, se eu não consigo identificar pelo próprio nome do objeto quais os papeis que ele desempenha tem algo de muito errado.
Em Rails eu sou obrigado por convenção e nomear determinadas classes, mas nos Frameworks em Java por exemplo não faz sentido.
Montei um exemplo aqui em cima de um caso real que fizemos, imagina um controller clássico assim
https://gist.github.com/cmilfont/39f892c2ba2937aa5f6d#file-indicacaocontroller-java
Voce identifica que é um controller pelo sufixo, mas a propria anotação já te ensinaria, não?
É um CRUD simples, recebe uma VO ou DTO via REST API por exemplo e grava uma entidade, mesmo assim voce tem um Controller, um Service e um DAO só para fazer isso. Sendo que o Hibernate é uma Engine que te fornece DAOs pra começar.
Eu poderia escrever algo mais simples usando VRaptor por exemplo assim:
https://gist.github.com/cmilfont/39f892c2ba2937aa5f6d#file-indicacao-java
Eu tenho uma entidade que já simplifica o código, expõe o que tem que fazer e já se comporta como Controller (tem a responsabilidade de).
Posso ainda simplificar mais usando um SpringMVC assim:
https://gist.github.com/cmilfont/39f892c2ba2937aa5f6d#file-indicacaocomspringmvc-java
Tenho uma classe no meu domínio que usa um DAO do hibernate, se comporta como service e controller.
Não sei se ficou claro agora, gostaria de ler sua opinião.
ps. montei agora direto no gist lembrando de um Case real que tivemos, nem sei se está compilando e desconsidere algum erro sintaxico, please 😀
Muito bom!!!! Obrigado pela “resposta-consultoria” hehehe bem fundamentada e esclarecedora.
Também li o artigo do Philip que vc linkou aí em cima e achei, realmente, interessante abriu minha mente kkk.
Obrigado, parabéns por compartilhar conosco, iniciantes nessa profissão tão desafiadora. 🙂
Crítica:
Estou relutando em não achar desse post mais um “Gente o Shoes disse que nomear controllers com sufixo é feio e não OO. A partir de agora vamos fazer isso!”
Acompanho o blog do Phillip e gosto das coisas que aprendo com ele, mas eu não acho que nomear um controller com sufixo quer dizer que seu código não é OO ou não segue boas práticas. Concordo que colocar TB em classes de domínio é uma péssima ideia (eu já vi projetos assim, realmente é terrível).
Não gosto da ideia de criterias no controller. Move-las para outras camadas como DAO/Repository dexaria seu código mais reutilizável.
Pena que o link do BOLOVO está quebrado.
Elogio:
Muito boa a parte que fala sobre DAO, Interface e Implementação, Service e Domain Driven Design.
Abs