Blog referente a aula do dia 26/05/2008
Solução
Consiste em inventar uma classe que suporte a coesão alta , acoplamento fraco e a reutilização, é uma classe fruto da imaginação, inventada de momento, o que acaba por tornar o projeto muito puro.
O problema se origina de maneira ao se atribuir responsabilidades apenas as classes de domínio, acaba por ocasionar problemas com coesão e acoplamento, ou pior tornam a classe impossível de ser reutilizada.
Veja um exemplo:
Pelo que entendi , a classe venda de acordo com o padrão especialista seria o responsável por salvar as suas próprias instancias em um banco de dados, só que é importante salientar que:
Seriam necessárias dúvidas operações de suporte relacionadas a banco de dados, nenhuma delas relacionadas a venda , o que tornaria a classe "Venda" não coesa.
Além disso a classe venda precisa ser acoplada ao banco de dados relacional aumentando assim o seu acoplamento.
Sendo assim , mesmo que o padrão especialista concorde que venda é a classe essencial para salvar a si mesma em um BD, ela leva todos os problemas que pedem que seja inventado algo e é aí que entra a invenção pura.
Uma solução seria criar uma classe exclusiva, exclusiva no sentido de ser utilizada somente para salvar os dados em um banco de dados relacional através de armazenamento persistente.
Peraí , mas o que vêm a ser "Armazenamento Persistente"??
Nada mais é do que algo criado por conveniência para auxiliar o desenvolvedor.
Segues abaixo alguns dos problemas resolvidos por invenção pura:
- A classe fica bem projetada com alta coesão e acoplamento fraco.
A classe armazenamento persistente por ser usada como auxilio ao desenvolvedor torna-se apta as ser utilizada várias vezes.
Por hoje é só pe-pe-pessoal, hehehe
Até semana que vêm.
BIBLIOGRAFIA:
http://groups.msn.com/cafedotnet/graspadress
UTILIZANDO UML E PADRÕES - Craig Larman
Solução
Consiste em inventar uma classe que suporte a coesão alta , acoplamento fraco e a reutilização, é uma classe fruto da imaginação, inventada de momento, o que acaba por tornar o projeto muito puro.
O problema se origina de maneira ao se atribuir responsabilidades apenas as classes de domínio, acaba por ocasionar problemas com coesão e acoplamento, ou pior tornam a classe impossível de ser reutilizada.
Veja um exemplo:
Pelo que entendi , a classe venda de acordo com o padrão especialista seria o responsável por salvar as suas próprias instancias em um banco de dados, só que é importante salientar que:
Seriam necessárias dúvidas operações de suporte relacionadas a banco de dados, nenhuma delas relacionadas a venda , o que tornaria a classe "Venda" não coesa.
Além disso a classe venda precisa ser acoplada ao banco de dados relacional aumentando assim o seu acoplamento.
Sendo assim , mesmo que o padrão especialista concorde que venda é a classe essencial para salvar a si mesma em um BD, ela leva todos os problemas que pedem que seja inventado algo e é aí que entra a invenção pura.
Uma solução seria criar uma classe exclusiva, exclusiva no sentido de ser utilizada somente para salvar os dados em um banco de dados relacional através de armazenamento persistente.
Peraí , mas o que vêm a ser "Armazenamento Persistente"??
Nada mais é do que algo criado por conveniência para auxiliar o desenvolvedor.
Segues abaixo alguns dos problemas resolvidos por invenção pura:
- A classe fica bem projetada com alta coesão e acoplamento fraco.
A classe armazenamento persistente por ser usada como auxilio ao desenvolvedor torna-se apta as ser utilizada várias vezes.
Por hoje é só pe-pe-pessoal, hehehe
Até semana que vêm.
BIBLIOGRAFIA:
http://groups.msn.com/cafedotnet/graspadress
UTILIZANDO UML E PADRÕES - Craig Larman
Nenhum comentário:
Postar um comentário