A tempos venho vendo a utilização de Design Patterns para resolver problemas técnicos( i.e. JNDI lookup, etc.), pouquíssimas pessoas utilizam patterns no negócio do cliente, para solucionar problemas que o business do cliente possui, etc.
Gostaria de saber a opinião de vocês, se vocês enxergam o mesmo problema.
Acho que isso acontece sim… Mas não sei dizer o motivo exato…
Aqui onde trabalho conseguimos modelar todo o framework que a equipe iria trabalhar, assim todos os problemas técnicos que poderiam ser resolvidos utilizando patters foram solucionados da melhor forma. No entanto, na implementação do negócio do cliente não houve planejamento, com os desenvolvedores olhando a descrição caso de uso e implementando diretamente. Acho que isso contribuiu bastante mas não acredito ser o único problema…
A tempos venho vendo a utilização de Design Patterns para resolver problemas técnicos( i.e. JNDI lookup, etc.), pouquíssimas pessoas utilizam patterns no negócio do cliente, para solucionar problemas que o business do cliente possui, etc.
Gostaria de saber a opinião de vocês, se vocês enxergam o mesmo problema.
Obrigado.
Até a próxima![/quote]
Fala Pessoal,
Design Patterns foram criados/catalogados com o intuito facilitar a resolução de um problema comum no desenvolvimento do “software”.
Já o para o negócio, cada um deve ser tratado de forma diferente. Cada empresa tem uma cultura, processos internos, ou seja, sua particularidade.
PS: Teve uma discussão bem interessante a respeito de Patterns aqui uma outra vez. Dá uma olhada:
Não encaro como um problema, mas como uma falta de cultura no máximo… Patterns são soluções amplamente testadas para problemas conhecidos, são soluções que devam ser utilizadas como via de regra.
Corrigindo o que alguém disse antes: Design Patterns foram criados/catalogados com o intuito facilitar a resolução de um problema comum no desenvolvimento do “prédios”.
Só depois é que foi adpatado para o desenvolvimento de software. Existem patterns para a área de negócio e seu mapeamento para técnicas de implementação. Acho que falta é cultura mesmo. A IBM tem um livro de Business Patterns. É um ótimo livro que eu recomendo.
[quote=marcos.macedo]
Corrigindo o que alguém disse antes: Design Patterns foram criados/catalogados com o intuito facilitar a resolução de um problema comum no desenvolvimento do “prédios”.
Só depois é que foi adpatado para o desenvolvimento de software. Existem patterns para a área de negócio e seu mapeamento para técnicas de implementação. Acho que falta é cultura mesmo. A IBM tem um livro de Business Patterns. É um ótimo livro que eu recomendo.[/quote]
Perdão, mas nunca ouvi falar de um tijolo “singleton” ou de um mestre de obras “observer”. Poderia nos dar um melhor exemplo dessa adaptação ?
Aproveitando, poderia compartilhar de sua experiência dizendo qual “Business Pattern” utilizado para resolver problemas em comum em mais de uma companhia que tenha trabalhado?
O nome “design patterns” foi cunhado por Christopher Alexander, um arquiteto (de tijolo mesmo) que viu que predios poderiam utilizar soluções em comum para os problemas que apareciam durante o desenho e a construção. A migração daí para informática foi só no nome mesmo, mas a criação dos primeiros patterns foi mesmo na área de construção civil.
O nome “design patterns” foi cunhado por Christopher Alexander, um arquiteto (de tijolo mesmo) que viu que predios poderiam utilizar soluções em comum para os problemas que apareciam durante o desenho e a construção. A migração daí para informática foi só no nome mesmo, mas a criação dos primeiros patterns foi mesmo na área de construção civil.
Concordo com você Nicholas, um exemplo da utilização do termo seriam os padrões utilizados na reconstrução da Alemanha pós-guerra. Porém, o enfoque dado não foi esse.