[list]
[b]- Minimize a acessibilidade de classes e membros
Prefira a imutabilidade
Prefira composição ao invés de herança
Especifique e documente para herança, caso contrário, proíba-a[/b]
[/list]
Herança é utilizada para definir subtipos. Quem criou o tipo HttpServlet achou [talvez com razão] que você não tem motivos para quebrar o encapsulamento, afinal: não era essa a sua queixa? Se você quer encapsulamento, por que fazer isso?
Se você precisa criar um Servlet HTTP novo, crie o seu do zero ou faça um adaptador [padrão da GoF] em cima do existente. Se você que um Servlet não-HTTP, extenda a superclasse.
Essa história de que toda classe rpecisa ser extensível é papo-furado
Sinceramente, você tá procurando chifre na cabeça de cavalo
Ate gostaria de poder seguir as dicas que voce passou. O fato eh que o modelo de servlets me obriga a seguir o modelo deles. Por exemplo, voce falou que prefira composicao a heranca. Bem, eu nao posso fazer uma composicao, porque envolveria criar um atributo, que nao funcionara direito em um ambiente multithread do Container WEB. Realmente estou pondo chifres em cabeca de cavalo. Fato: preciso criar um servlet. Fato: Meu servlet nao pode ter propriedades (nao eh thread safe).
Que opcoes eu tenho para contornar isso: Ficar grudando coisas do request, na sessao, que eh tosco, do ponto de vista de orientacao a objeto. Se eu tenho uma Classe que eh um Servlet que trata da logica do dominio X, nada mais justo que informacoes sobre esse dominio possam ser armazenadas nele. Pois bem, eu nao posso. Tenho que ficar grudando essas coisas em session, request.
Mesmo que eu extenda a Servlet, nao a HttpServet, o container esta preparado para pensar em instanciar somente um unico Servlet do meu tipo. O contrato da API especifica que o Servlet, e o HttpServlet precisa ser thread safe, ou seja nao permite o uso de atributos. Ate existe um SingleThreadModel, que eh altamente nao recomendavel, que faz um lock do objeto inteiro, serializando os acessos ao servlet, sem nocao.
Acho que essa discussao esta se distanciando muito do seu foco. Mesmo com todos esses problemas conceituais do Servlet, eh possivel usar ele com destreza. Fazer programas otimos.
Nao venha tambem me dizer que os genios que inventam essas nabas estao certos. Citando exemplo, o controle de thread , por exemplo, na versao do java 1.0 possuia o infame metodo stop. Ele foi deprecated e altamente desaconselhado porque podia segurar locks de monitores e de recursos. Erros de design ocorrem a todo o momento. Soh nos resta aprender a confivever com eles. Eh o caso do servlets. Tem que ir consertando aonde da. Eh ai que entram frameworks tipo Struts e WebWork.
Bom, se você coloca regras de negócio nos servlets, acho que o problema não é bem da API…
Eles servem apenas para executar métodos em resposta à eventos HTTP, você não deveria estar precisando colocar atributos em cima dele, porque servlets NÃO fazem parte da lógica de negócios, são clientes dela!!
O padrão Adapter poderia muito bem ser utilizado em um contexto multithread, o Servlet encapsulado recebe as solicitações, qual o problema?
O problema é que você está colocando sua lógica de negócios no lugar errado. Me dê um bom motivo para colocar um atributo em um servlet.
Problemas acontecem em qualqeur projeto, acho que até você falou isso neste t’ópico. Qual o problema em errar? Nada é perfeito, nem ninguém…
Tudo baseado nos servlets. Um exemplo clássico é JSP: são abstrações dos servlets!! Não são gambiarras para melhorar o modelo, são um método de implantar MVC, servlets são apenas conectores entre o programa e o mundo HTTP, estes frameworks não substituem servlets, eles os encapsulam e põe um lindo ‘COLOQUE SUA REGRA DE NEGÓCIO AQUI’ para facilitar as coisas.
Antes de falar que servlets são mal-projetados [eles não são perfeitos, ok, ams seus argumentos não apontaram nada], revise quantas camadas tem seu sistema. Qual a diferença entre um servlet ‘faz-tudo’ e uma aplicação Delphi/VB conectando com o banco? Novamente: me dê um bom motivo para extender um servlet ou colocar um atributo nele, a menos que você não esteja usando HTTP.
na epoca que nao tinha filtro, todo mundo criava uma SecurityServlet que o doRequest6 verifica se o cara estava logado, e se estivesse3 chamava o metodo abstrato execute(). Eu nao gosto disso, mas eh um motivo ai, template method.
mas meu ponto nao eh esse, meu ponto eh que sua aplicacao deve ser agnostica a api do servlet, como o webwork.
bem, realmente nao eh algo super necessario. mas ficar agnostico o codigo fica mais limpo, e mais facil de ler. alem disso fica mais facil de testar (apesar de eu nao ser o homem teste, como o cv bem sabe :))
achava que voce tambem curtia o webwork pela agnosticidade com a api de servlet cv, qual a sua opiniao/gosto?
E eu curto, eu acho uma das coiasas mais legais do WebWork o fato de ele te isolar da API que ta por baixo dos panos. Mas dizer que todos os casos devem ser tratados assim tira muito do seu leque de opcoes. Legal, vc pode pegar uma app escrita em cima do WW2/XW e fazer suas Actions rodarem em cima de um ambiente totalmente diferente (sei la, Swing), mas toda abstracao falha, e alguma hora voce precisa de um cookie. Whoops.
Entao, reiterando, eu gosto da liberdade de nao ter que me preocupar com o HttpServletRequest ou o que mais for. Mas dizer que é errado ou anti-pattern descer pras camadas de abstração mais baixas quando necessário, eu discordo, e foi mais ou menos isso que eu interpretei do post do Guilherme. Pronto, pode me chamar de mala
Trabalho só com o WW 1.4 faz um ano ±, e a única coisa que que tenho tenho a dizer é que o WW é bom dependendo do que vc quer fazer… nào uso o WW2 pq ele nunca fica pronto, tbm não posso me dar ao luxo e ficar mudando minha aplicação pq alguem resolveu tirar esse ou aquele método e por último se a documentação do 1.4 já é muito fraca imaginem a do 2.
Hoje predendo implementar uma aplicação um pouco maior e estou estudando o struts pra fazer isso… por dois motivos, achei o struts mais parrudo, principalmente na parte de Internacionalização e Localização, muito mais recurso que o WW1.4 e o motivo principal, a documentação é esmagadoramente maior… Como que com o WW eu não uso velocity ou similares, prefiro trabalhar com tags, na parte do view não vou ter problemas…
Na minha opnião, quando vc usa ferramentas openSource em projetos profissionais vc não pode arriscar… Sem contar a disponibilidade de profissionais caso você precise… Usando uma ferramenta popular posso ter um programador que já “vai chegar programando”… essa é uma vantagem tbm.
Vou continuar usando o WW para aplicações menores e mais simples uma vez que a lógia é muito semelhante entre o WW e o Struts.
Creio q radicalizar não é muito legal… Gosto muito do WW, é uma maneira fácil e rápida de alguém que tá ingressando no mundo MVC, criar suas aplicações, talvez se eu tivesse entrado diretamente no Struts teria pastado muito mais!!! Mas quando o bicho pega vc precisa de uma solução mais Robusta…
Ola pessoal
Entrando no meio aki… Eu tb nao gosto de extender x ou y, implementar teta e o escambal… Meu trabalho de diplomacao aborda programacao orientada por aspectos, e nele estou fazendo uma aplicacao web simples (simples messssmmmmoooo) e usando o AspectJ para em alguns casos funcionar como “cola” entre as api’s e minha lógica de negócios…
Quando terminar , defende-la e corrigi-la (espero q nao precise) publico aki pra vcs darem uma olhada (e jogaram pedras )…
[quote=“Guilherme Silveira”][
extendendo uma servlet pra:
na epoca que nao tinha filtro, todo mundo criava uma SecurityServlet que o doRequest6 verifica se o cara estava logado, e se estivesse3 chamava o metodo abstrato execute(). Eu nao gosto disso, mas eh um motivo ai, template method.
[/quote]
Na época que eu fazia CGI, era bem legal. Hoje você me pede um CGI e eu te mando pra PQP
)…