search

Prof-Calebe / substituicao

Sistema de controle de Substituição de Professores
7 stars 18 forks source link

Proplemas no Model #12

Open LuisTessaro opened 8 years ago

LuisTessaro commented 8 years ago

Nenhum deles possuí se quer uma forma de designar ou recuperar seus atributos além de não possuírem um construtor do padrão.

calebepb commented 8 years ago

A designação ou recuperação é feita por meio de atributos public. Verificar se isso é realmente necessário. Quanto aos construtores padrão, só existirão se foram necessários. Aliás, o que é necessário para estas classes do pacote model? Acho mais interessante refatorar o nome delas, retirando o sufixo Model, principalmente porque o pacote está em português e o sufixo em ingles..

calebepb commented 8 years ago

Aliás, percebi que existem dois pacotes estranhos: modelo e dominio. Qual a diferença deles?

LeoFuso commented 8 years ago

Calebe, realmente, as classes em modelo parecem ser apenas versões mais antigas das classes implementadas em domínio. Uma espécie de resquício de uma iteração mais inicial do projeto.

LeoFuso commented 8 years ago

Depois de começar as alterações percebi que as classes modelo eram usadas para get e set fáceis. Muitas partes do sistema que precisavam mandar ou receber Usuarios, por exemplo, mas não utilizavam seus métodos, utilizavam o modelo. Algumas classes do View também utilizavam UsuarioModel.

Eu substituí com sucesso todos os UsuarioModels por Usuario sem problema nenhum. Eu inutilizei por completo aquela classe.

Só que eu fiquei em dúvida, pois mexi em muitas classes, inclusive algumas de testes.

Não sei se é correto continuar inutilizando classe por classe do pacote de Model. Pois mesmo repetidas, elas são utilizadas. Podem ser substituídas pelas classes de domínio? Parece que sim. Mas devem? Essa parte que estou em dúvida. Não sei se devem ou não. Não sei mais qual foi o propósito original delas.

calebepb commented 8 years ago

Opa, vamos lá. Se as classes de modelos era utilizadas apenas para getters/setters elas são apenas DTO/VO. Tem seu papel quando é para "trafegar informações" entre camadas, mas não possuem valor de negócio. Se elas eram para persistência, novamente, seu papel está errado. Mais um motivo para rever essas classes. Da forma como você descreveu, a resposta é: sim, elas devem ser trocadas. Mas, não achei a sua branch para olhar o resultado dessa conversa...

LeoFuso commented 8 years ago

Eu também não achei a minha branch, o que é estranho, pois ela existe. Vou verificar isso e continuar trocando as outras classes.

LeoFuso commented 8 years ago

Felizmente elas não eram usadas para persistência. Só tráfego de informações para o front end mesmo.

LeoFuso commented 8 years ago

Já realizei o pull-request. Nota que, aparentemente, o Júlio fez uma classe de testes para uma das classes inutilizadas pelo pull request,