[quote=bKn][quote=YvGa]
Sim, tudo na mesma, separar regra dos dados nao tem necessidade, se uma classe possui os dados, qual o problema de conter as regras aplicadas sobre eles? ContaBLL, Conta? Pra que?
[/quote]
Para desacoplar a camada de negócio e torná-la orientada a objetos. Para centralizar o seu comportamento e promover o reuso. Para evitar duplicidade e melhorar a manutenção do código. Para promover uma arquitetura orientada a serviços.
[/quote]
Com isso voce nao a esta tornando orientada a objeto, esta fazendo justamente ao contrario. Separar dados e regra, nao evita duplicidade, nem promove reuso. Separar dados e regras é programacao procedural com variaveis e funcoes.
Nao, nao diminui a quantidade de regras, mas aumenta muito a legibilidade do codigo. Uma classe com 1000 linhas estara repleta de if-else e código que podia estar mais bem organizado. Qualquer alteracao que precise ser feita, por menor que seja, leva horas só pra encontrar o lugar, ou os lugares (na maioria dos casos) onde ela deve ser feita.
Repare que eu fiz uma pergunta ao criador do topico, em nenhum momento disse a ele como ele tem que fazer, muito menos disse “ai meu rim” para a implementacao que ele propos. Eu perguntei por que, com o intuito dele avaliar a decisao dele. Quem sabe ele tentando uma explicacao vai perceber que nao esta tomando a melhor decisao.
Não é raro validar estados de entidades de acordo com estados de outras. Fazer isso com DOs, na minha concepção, é extremamente bolorento, e cria sim duplicidade, a menos que se aumente o acoplamento entre elas. Deixar regras de negócio dentro de entidades é atribuir à elas responsabilidades que muitas vezes não lhe dizem respeito.
De que maneira? Não vejo como isso é possível.
O que te faz concluir isso? Antes saber que terei de modificar a minha classe de negócio do que modificar a entidade em si, podendo ocasionar erros em todo o resto da minha aplicação que a manipula.
[quote=bKn][quote=YvGa]
Com isso voce nao a esta tornando orientada a objeto, esta fazendo justamente ao contrario. Separar dados e regra, nao evita duplicidade, nem promove reuso. Separar dados e regras é programacao procedural com variaveis e funcoes.
[/quote]
Não é raro validar estados de entidades de acordo com estados de outras. Fazer isso com DOs, na minha concepção, é extremamente bolorento, e cria sim duplicidade, a menos que se aumente o acoplamento entre elas. Deixar regras de negócio dentro de entidades é atribuir à elas responsabilidades que muitas vezes não lhe dizem respeito.
[/quote]
Validar o estado de objetos baseado no estado de outros objetos sim é alto acoplamento, pois se para um objeto ser valido é preciso que outra seja valido eles estao acoplados. Isso nao só deveria ser raro, mas evitado a todo custo (exceto no caso da relacao root-agregates). Como pode nao ser responsabilidade de um objeto realizar operacoes sobre os seus proprios dados? Quem mais pode ter a responsabilidade de alterar o estado de um objeto se nao ele mesmo? Em que isso aumenta o acoplamento? Lembre-se que um objeto nao é composto por dados e regras, mas por estado e comportamento. Separar o estado do comportamento é caminhar na direcao procedural, onde funcoes alteram o valor de variaveis. É o que voce esta fazendo separando o estado do comportamento.
Voce acha mais facil entender o que faz um metodo com 500 linhas do que um com 5?
Hmmm, ja ouvi essa expressao em algum lugar. Algo como o inferno das variaveis globais??? Encapsule os dados e esse medo diminui bastante.