Primeiro assunto: Protecting the Domain Model
Novo assunto: em qual idioma codificar?
Próximo assunto: o que é ambiguidade?
[quote=Rafael Nunes][quote=Thiago Senna]Não CV… Neste caso o problema não é as pessoas que são ambíguas. Quando se trata de uma dissertação é fácil utilizar ambiguidade. Afinal, em um vestibular os vestibulandos devem saber destinguir textos que contém ambiguidade, já que essa é uma exigência dentro de qualquer vestibular e até mesmo no currículo escolar!!! 
Uma coisa é utilizar uma língua para se comunicar, outra coisa é saber se comunicar de forma eficiente, garantindo que a sua informação está sendo devidamente interpretada!
Abraços
Thiago[/quote]
Eu concordo com o cv, a ambiguidade esta em quem escreve. A ambiguidade esta na ideia, e nao no conjunto de palavras que formam a frase.
Quem fala/escreve e quem tem o dever de ser inteligivel/nao ambiguo, e nao o interloucutor.
Mas voltando ao off-topic que ja nao e mais o assunto do topic tambem, eu codifico em portugues no trampo e ingles para meus projetos[/quote]
Nana nina não Rafael… rsrs…
Infelizmente não tenho exemplos agora… mas já vi textos perderem totalmente seu real sentido por causa de uma vírgula!
Bom… vou dar um exemplo nada a ver com a vírgula, mas que poderia sem problemas se usado por uma pessoa, sem que ela tivesse algum tipo de Malícia!
:arrow: Jeniffer é uma professora boa!
No texto acima deu para perceber a ambiguidade?
O texto acima pode ser modificado para que não passe essa impressão. Como no Brasil a educação não é lá aquelas coisas, e com toda a dificuldade que a língua portuguesa já possui, acho que é perfeitamente possível usarem ambiguidade mesmo que sem intenção.
Como… por insistir no OFF-TOPIC! Voltando ao assunto do tópico…
Eu prefiro usar inglês, acho muito mais fácil criar métodos que condiz com sua função usando esta língua. Em algum projeto uso Português mesmo, mas acho inglês muito mais fácil e ágil, apesar de eu ser um admirador da língua Portuguesa!
Abraços!
Thiago
Esse eh o GUJ :mrgreen:
Voltando ao tópico (ufa!).
Considerando três alternativas que li no TSS ( no meio de um monte de posts inúteis):
- (D)TOs inter-camadas
- Helper classes para criar visualizações para as camadas
- Interface se virando para extrair o que precisa dos objetos de domínio
Eu acho que ficaria com qualquer uma menos a primeira. Primeiro que não seriam DTOs, seriam Views, ou algo do tipo, eles não transfeririam dados, apenas apresentariam os dados de uma maneira amigável á interface.
Eu classificaria isso como uma complexidade acidental e criaria um Context Map para traduzir conceitos de domínio em telinhas (assim como um DAO faz).
O LIPE tem experiência com isso (quem não viu ele um mês e pouco tentnado criar um framework apra representar atributos em componentes swing?).
Shoes
Acho que os dois primeiros estão dizendo a mesma coisa, só que com buzzwords diferentes. O negócio não é simplesmente usar DTOs, é encapsular processamento que iria pra view em objetos pra ajudar a view a trabalhar(os helpers que o Philip falou).
Pense em quando você tem uma lista de produtos e quer mostrar o resultado dos preços de todos eles na view, a view não deveria ter a responsabilidade de somar todos os produtos, então você cria um objeto ListaDeProdutos, mete a coleção de produtos lá dentro e pergunta a esse objeto o valor total dos produtos.
Acho que tá na hora de refatorar quando agente começa a pensar em formatar esse ou aquele String que tá saindo lá do modelo, ou quando tem aquele objeto Date de vacilo por ali que poderia ter uma saída mais bonitinha…
Acho que é por isso que eu gosto de usar expression language, não deixa você chamar métodos nos seus objetos 
O problema dos DTOs é uma hierarquia de classes independente e artificial, manualmente sincronizada com suas hierarquias de domínio. Com helper classes você não precisa criar um “mundo bizarro” paralelo.
Se esse conceito de soma é importante a ponto de aparecer na tela, provavelmente tem alguma abstração que o implementador não entendeu no domínio.
Formatar do tipo transformar “4” em “R$4,00” ou “IV” tudo bem, o problema é quando se tem que alterar o valor ou o significado do dado.
Shoes
Sim, e isso acontece em qualquer lingua que as utilize. “Thiago e um burro” e “Thiago é um burro” sao bem diferentes, mas a unica coisa que mudou foi um misero acento. Da mesma forma, “Thiago’s an asshole” e “Thiago’s asshole”.
A lingua portuguesa nao tem nenhuma dificuldade. Pessoas tem dificuldade com a lingua portuguesa, da mesma forma que a lingua portuguesa nao tem ambiguidades - pessoas tem diferencas cognitivas e a ambiguidade (proposital ou nao) sai dai.
Continuo sem ver diferenças entre os DTOs e as view helpers, o resultado final vai terminar sendo praticamente o mesmo, a não ser que o carinha tenha realmente coragem de montar um DTO pra cada classe do modelo e eu acho que ninguém faz isso, ou faz? :shock:
No fim, tem que fazer mais algumas classes (sejam DTOs ou view helpers) pra não colocar processamento na visualização.
CV… considero o seguinte exemplo abaixo:
Vc e seu amigo estão em uma sala de aula, e entra uma professora horrorosa que dá uma aula espetacular pra vcs… simplesmente uma ótima aula! Daí seu amigo te diz:
O que você entendeu quanto a colocação de seu amigo?
Agora considere este outro cenário:
Vc e seu amigo estão em uma sala de aula, e entra uma professora muito gostosa que dá uma aula escrota … onde todos os alunos prestavam atenção atentamente no gingado da professora enquanto apagava a lousa!!! No final da da aula seu amigo te diz:
O que foi que seu amigos quis dizer? Hein?
Dependendo do contexto, e da forma como se vê a situação as mesmas palavras e frases passam a ter sentido diferente!
Essas ambiguidades são possíveis em qualquer língua, mas no caso do Português isso é mais acentuado do que no caso do Inglês!
Falar em inglês para um nativo a frase… She’s a good teacher para indicar que uma professora sabe ensinar bém é perfeitamente válido, mas usar a mesma frase para indicar que a professora é gostosa essa frase não é válida… provavelmente vc teria que usar outro ajetivo para passar este tipo de informação…
Quanto ao seu exemplo usando o Thiago’s Burro não vejo ambiguidade alguma. Independente do contexto sempre serei burro do mesmo jeito!
Abraços!
Thiago
Nao, nao eh, e pare de teimar, saco. :evil:
Se voce vai usar exemplinhos carimbados pra provar que uma LINGUA eh mais ou menos ambigua que outra (coisa que nem sequer pode ser, pra comeco de conversa, como eu ja disse antes), entao tudo bem, eu vou entrar na brincadeira tambem: “This chicken is hot!” quer dizer que a comida ta quente em temperatura ou em pimenta? Ou quer dizer que voce faria sexo com o frango caso ele te desse bola?
Kkkkkkkkkkkkkkkkkkkkkkkkkkk!!!
:mrgreen:
De Domain Model pra zoofilia, eu amo o GUJ! :lol:
É só uma discussão. Não há motivo para stress! wink:
Fazer sexo com frango da dor nas costas! Comer tatu também… vc nunca ouviu aquela música dos mamonas???
Os exemplinhos são sim escrotos… e num vale a pena entrar nesse joguinho de quem come quem! Eu disse que em qualquer lingua é possível haver falsas interpretações por causa de ambiguidade!
Achei escroto a colocação que haviam feito de que a ambiguidade está nas pessoas. A ambiguidade esta em uma comunicação mau realizada, mas não na pessoa. E a língua somada a cultura de um povo acentua ou não esses problemas!
Vide qualquer gerente… uma ordem que ele te dá tem 1001 interpretações! Se a língua não fosse problema, não teriamos problemas com as n interpretações que fazem nos códigos penais!!!
Abraços!
Thiago
Sim, mas voce disse isso pra reforcar de que a ambiguidade do portugues eh maior que a do ingles. O que nao eh verdade - a ambiguidade, de novo, esta na presenca (ou nao) de contexto na cabeca dos interlocutores. Ou seja, esta nas pessoas, nao na lingua.
Voltando o assunto.
Sobre DTOs.
É melhor ter um DTO para cada requisição ou um DTO que representa uma entidade.
Sei que é uma pergunta estranha mas vou exemplificar:
class Departamento {
private int codigo;
private String descricao;
}
class Funcionario {
private int codigo;
private int nome;
private Departamento departamento;
// getters and setters
}
é melhor ter
class DepartamentoDTO {
private int codigo;
private String descricao;
}
class FuncionarioDTO {
private int codigo;
private int nome;
private DepartamentoDTO departamento;
// getters and setters
}
class EJB {
public FuncionarioDTO consultarFuncionario(int codigo) {
FuncionarioDTO fDTO = new FuncionarioDTO();
DepartamentoDTO dDTO = new DepartamentoDTO():
Funcionario f = Funcionario.consultar(1);
fDTO.setCodigo(f.getCodigo());
fDTO.setNome(f.getNome());
dDTO.setCodigo(funcionario.getDepartamento().getCodigo());
dDTO.setNome(funcionario.getDepartamento().getNome());
fDTO.setDepartamento(dDTO);
return fDTO;
}
public void cadastrarFuncionario(FuncionarioDTO fDTO) {
Funcionario f = Funcionario.criarNovo();
f.setCodigo(fDTO.getCodigo());
f.setNome(fDTO.getNome());
Departamento d = new Departamento();
d.setCodigo(fDTO.getDepartamento().getCodigo());
f.setDepartamento(d);
f.cadastrar();
}
}
ou
class CadastrarFuncionarioDTO {
private int codigo;
private int nome;
private String codigoDepartamento;
}
class ConsultarFuncionarioDTO {
private int codigo;
private int nome;
private int codigoDepartamento;
private String descricaoDepartamento;
}
class EJB {
public ConsultarFuncionarioDTO consultarFuncionario(int codigo) {
ConsultarFuncionarioDTO fDTO = new ConsultarFuncionarioDTO ();
Funcionario f = Funcionario.consultar(1);
fDTO.setCodigo(f.getCodigo());
fDTO.setNome(f.getNome());
fDTO.setDescricaoDepartamento(f.getDepartamento().getDescricao());
fDTO.setCodigoDepartamento(f.getDepartamento().getCodigo());
return fDTO;
}
public void cadastrarFuncionario(CadastrarFuncionarioDTO fDTO) {
Funcionario f = Funcionario.criarNovo();
f.setCodigo(fDTO.getCodigo());
f.setNome(fDTO.getNome());
Departamento d = new Departamento();
d.setCodigo(fDTO.getCodigoDepartamento());
f.setDepartamento(d);
f.cadastrar();
}
}Neste exemplo a ação de cadastrar tem apenas um campo a menos em relação a ação de consultar.
Mas imagine se tivesse 10 campos a menos quanta diferença isso faria ?
So pra nao dizer que eu pelo menos nao participei do assunto original dessa thread, eis um link :mrgreen:
http://jroller.com/page/cpurdy/20050603#an_interesting_topic
Gostei das conclusoes do Cameron, e mais ainda dos comentarios. Leiam!
Sei não, o que eu to vendo aí é muito código repetido, FuncionárioDTO tem que usar a própria classe Funcionario pra carregar um FuncionarioDTO, uma coisa, no mínimo, bizarra :shock:
Não estou vendo utilidade nenhuma em usar esse DTO, o que é que ele fez que o objeto do modelo não faz?
jprogrammer, a melhor estrategia eh nao ter DTOs nem DAOs - de novo, leia:
Eu adoraria usar persistência simples, mas meu ambiente não me fornece Mapeamento O-R automático, menos ainda lazy-loading.
Como muita gente usa um engine para isso hoje em dia, pode ser uma boa, mas não é a melhor em qualquer caso (e eu aidna tenho minhas dúvidas em muitos casos).
Shoes
[quote=cv]So pra nao dizer que eu pelo menos nao participei do assunto original dessa thread, eis um link :mrgreen:
http://jroller.com/page/cpurdy/20050603#an_interesting_topic
Gostei das conclusoes do Cameron, e mais ainda dos comentarios. Leiam![/quote]
Pois é, a solução de um pode não ser a mesma pro outro. No caso específico do cara lá do sistema de telecomunicações, ele tem uma classe externa que faz o “serviço” de ligar todo mundo, o “todo mundo” não precisa saber como e que eles foram ligados. Isso me faz pensar em um jogo de xadrez, quem é que mexe? É a peça que sabe se mexer pelo tabuleiro? É o tabuleiro que diz pra onde a peça tem que se mexer? Ou é uma entidade externa que decide pra onde a peça pode se mover?
E isso é uma coisa que todo mundo deveria pensar muito:
Estudar as coisas sobre as quais estamos desenvolvendo!
A questão é desacoplar o client do domain model.
Imagine se eu usar o lazy-loading e mandar o próprio objeto de dominio para o client. Isso pode ter resultados inesperados…
O client terá que saber como o domain model se persiste ou se recupera.
Mandar um DTO por mais que ele parece “imbecíl” para o cliente é uma boa ideia nesses casos.
Mesmos em lazy-loading, você pdoeria ter objetos muito pequenos que iam acarretar numa enxurrada de chamadas pela rede, um DTO empacota tudo que o cliente vai precisar ao máximo possível.
O problema é que o artigo fala em DTO para passagem entre camadas pura e simplesmente, não entre nós. Nesse caso, você pdoe usar lazy-loading na maioria dos cenários sem rpoblemas, mas seu cliente pode exigir que os dados estejam em um formato que não é a do objeto de domínio, jhá que este é construído para resolver problemas, não para exibir dados a um usuário (por exemplo).
Shoes