Li o Padrões de Projeto do Use a Cabeça, mas tenho de confessar que fiquei no ar quanto alguns padrões como o MVC e assim quanto a forma de comunicar partes do projeto, por assim dizer devo criar classes de fronteira ou acessar as entidades diretamente, enfim.
Onde posso aprender mais sobre padrões de projeto e que me mostre um pouco mais sobre o caminho real ao projetar um software com exemplos?
Quais são bons catálogos de padrões de projeto pra carregar de baixo do braço?
Qual seria um bom e completo livro de engenharia de software em português, onde possa aprender sobre requisitos, metodologias de desenvolvimento, …?
Quanto a isso qual seu objetivo na pratica? Vai ficar mais facil de voce entender se tiver algum caso para praticar. E veja uma coisa de cada vez.
uma coisa que acho importante e dar preferência para as soluções mais simples e apenas fazer o uso de um padrão (não falando desses padrões estruturais de projeto que utilizamos no dia a dia ex: MVC) mas dos padrões que que fazem a diferença no modelo lógico estou falando daqueles padrões que utilizamos para resolver problemas diretamente ligados ao desenvolvimento do software e não apenas usar padrões pelo modismo da época, opto sempre pela simplicidade que não é sinal de mal feito e sim bem ao contrario.
Certeza de que quanto mais deles na bagagem maior número de soluções tera e sabera a hora de usar e combinar eles, existem muitos outros livros de padrões de projetos como padroes GOF e tem um livro que considero uns dos melhores que ja li pois me abriu muito a mente na forma de pensar em design e arquitetura de software que é o livro da caelum segue indicação:
http://www.arquiteturajava.com.br/ sucesso amigo, abraços.
Acho que o melhor caminho agora é aprender inglês!
Mas, padrões de projeto não são bem assim, um guia de consulta. Muito menos, você precisa decorar os padrões.
A medida que for amadurecendo na sua programação você verá situações onde aparece um padrão ou outro. Assim, você já começa a se familiarizar com as soluções.
Não vai adiantar ler mil livros, pois você não sairá de toda dessa leitura sabendo ler e aplicar padrões de projeto.
Eu costumo dizer que você aprende é a usar as filosofias que são a base dos padrões, como por exemplo, programar para interfaces, e favorecer composição ao invés de herança.
Em resumo, aprender a fazer um bom design de uma solução de programação requer amadurecimento. E isso, é com a prática mesmo.
Mas agora, sabendo que existem certos padrões você amadurece mais rápido.
Um livro que acho legal é Design Patterns Explained… ele existe em português também mas não consegui achar um link.
A capa dele em português é igual. Se não me engano o nome é Design Patterns Explicado.
[quote=DavidUser]Li o Padrões de Projeto do Use a Cabeça, mas tenho de confessar que fiquei no ar quanto alguns padrões como o MVC e assim quanto a forma de comunicar partes do projeto, por assim dizer devo criar classes de fronteira ou acessar as entidades diretamente, enfim.
Onde posso aprender mais sobre padrões de projeto e que me mostre um pouco mais sobre o caminho real ao projetar um software com exemplos?
Quais são bons catálogos de padrões de projeto pra carregar de baixo do braço?
Qual seria um bom e completo livro de engenharia de software em português, onde possa aprender sobre requisitos, metodologias de desenvolvimento, …?[/quote]
Vc quer aprender design e arquitetura em dois dias … complicado…
Projetar um caminho para o projeto requer experiencia e mesmo assim é complicado.
Os catalogos de padrões existem e sim servem para ser consultados. É como uma caixa de ferramentas onde cada ferramenta vem com instruções.
Um dos mais conhecidos é o do Martin Fowler e o do Gang of Four .
Estes são os mais básicos. Depois ha outros como o MVC , o Produtor-Consumidor e alguns outros que escapam desses catalogos, mas são importantes.
Material sobre isso é só procurar na web , tem o http://hillside.net/patterns/links com alguns links que vc pode seguir. o Hillside é um repositorio de patterns, mas nem todos são de desenvolvimento de software. Tem patterns de aprendizado e de escrita por exemplo. Em portugues é mais dificil. Eu tento manter um catálogo em http://www.javabuilding.com/academy/patterns.html que eu tento compilar de outros lugares, mas ha muita coisa e ainda não tem todos os que eu gostaria.
Quando vc comunicar um projeto não utilize os nomes dos patterns, fale sobre as responsabilidades. Os patterns derivam das responsabilidades.
Para modelar vc tb não precisa dos patterns. Eles podem ajudar e podem acelerar , porque são uma linguagem. Quando vc fala uma linguagem e pensa com ela, é mais simples ( o famoso “pense em inglês, não traduza”) Mas os patterns não são especialmente necessários para poder raciocinar sobre a arqutetura e o design. Coisas mais simples como o conceito de nodo , andar e camada, os princípios SOLID , o principio de DRY e mais alguns outros são a base que cria tudo o resto. Inclusive os patterns.
É um conhecimento adquirido e destilado ao longo do tempo. Mas arquitetura não é apenas codigo e patterns. Tem o lado de requisitos, de negocio de entender as necessidades , e tem o lado de gerenciamento, de orçamento, cronograma, entender os constrangimentos, etc… Se o cliente lhe pede um sistema em três meses para apresentar em uma feira e lançar o produto dele, suas escolhas serão umas. Se vc tiver 8 anos , serão outras. Se lhe pedirem um software ERP é uma coisa, se lhe pedirem o software de monitoramento de equipamentos médicos é outra. Não existe “receita de bolo” no sentido que cada sistema é único, mas ha receitas e boas práticas que sempre são válidas e devem ser conhecidas e praticadas. E algumas ficam mecanicas. É como os chefs que picam cebola rápidamente. Isso é apenas um ingrediente, mas eles aprenderam a lidar com ele da forma mais eficiente.