Bom dia, estava analisando aqui em relação a projetos e vim alguns programadores fazer pacotes com nomenclatura de Dao, Model, View, Bean. Ai já sabe iniciante viu algo e já que aprender e colocar em pratica, gostaria de saber se ah alguma lógica para poder estudar e implementar no projeto ou é só um método de organização e boas praticas de programação? Não sei o nome que desse método para estudar e poder testar, então gostaria de saber o nome e conteúdo para estudos e poder testar tbm. Obg pela atenção.
Veja, DAO é um padrão.
Model/View fazem parte de outro.
É muito comum que se utilizem vários padrões distintos em um mesmo projeto.
O que estudar?
Design patterns. GOF e não GOF (Gang of four - os 4 caras que manjam tudo de padrões).
No meu entendimento, é uma coisa chata, mas fundamental de se estudar.
2 curtidas
Caso queira se aprofundar nos conceitos, dê uma lida sobre Domain-Driven Design (DDD) -> Cuidado! Alta complexidade
2 curtidas
tenho duvidas, tipo, com a programação OO já não da uma agilidade e organização, pelo fato de criar varias class e podendo criar métodos. Sera possível vc me informar algum github ou vídeo de algum projeto usando Design patterns?
Você diz isso por não conhecer de OO, provavelmente.
Ah, meu caro, tem tanta coisa sobre design patterns, incluindo livros. Tem apostila da caelum sobre isso.
1 curtida
Reli este trecho e acho que meu comentário anterior foi equivocado, devido ao modo como você escreveu.
Sim, a orientação a objetos te dá uma agilidade e organização. Porém, ela é um paradigma de desenvolvimento. Você pode optar, por exemplo, por programar estruturado.
Ainda assim, vai precisar definir um padrão para acesso a um elemento de persistência. Em geral, um dos padrões mais utilizados é o DAO - Data Access Object (objeto de acesso a dados), que consiste em abstrair a camada de persistência, permitindo que você foque na execução e não no comportamento (eu quero fazer X, Y ou Z, sem me importar como o DAO vai funcionar). Porém, DAO não é o único pattern para persistência, existem outros, como o active record (que ganhou mais notoriedade com o ruby, especificamente, ruby on rails).
Da mesma maneira, você precisa definir um modelo de organização para a parte do sistema que interage com o usuário/utilizador (pode não ser uma pessoa, mas, outro sistema). Aí você opta por um padrão como MVC ou Façade, com um uso muito maior do primeiro.
Agora que você definiu essa estrutura, como pretende trafegar o que vem do usuário/utilizador? Aí você pode definir um modelo de transição de objetos, como os famosos TOs - Transfer Objects.
Você desenvolveu uma solução desktop onde precisa que, ao clicar num botão, abra uma nova janela, onde há opções a selecionar. Ao clicar em “Finalizar”, essa nova janela fecha-se e você precisa dos dados selecionados na janela oroginal. #Comofas? Usa o pattern observer (ou algum outro que atenda o caso).
Notou? Você dificilmente usará apenas um padrão.
Também pode usar padrões sem nem saber o nome deles.
Em geral, temos pilhas de padrões (como a pilha de protocolos TCP/IP, fundamental para a internet) e é isso.
2 curtidas
Querer usar OO pra tudo realmente não dá agilidade, aumenta a complexidade sem muitas vezes nao ter a necessidade. O ideal é mesclar paradigmas, avaliar se em determinado caso será melhor procedural, funcional ou OO. Maioria das linguagens são multi-paradigma. A organização e reutilização de código pode ser feita procedural, funcional ou OO.
1 curtida
entendi, obg
obg pela força.
1 curtida