Este artigo foi traduzido por máquina.
Nota do editor
Padrões na prática
Nos últimos meses vários MSDN Magazine congratulou-se um par de colunas novas —Rachel AppelApps moderno e Bruno Terkalye Ricardo Villalobos' Windows Azure Insider. Nós também vimos Charles Petzold rebrand sua coluna como fator de DirectX, refletindo sua mudança para explorar a infra-estrutura do DirectX do Windows Runtime. O que você pode não saber é que nós também estivemos ocupados no Web site. Em Janeiro, nós introduzimos uma nova coluna online mensal chamada padrões de prática, escrito pelo veterano autor de MSDN Magazine Peter Vogel.
Como sugere o nome da coluna, padrões na prática explora o valor e o potencial de padrões de design, aplicando-os em cenários de trabalho. Em sua coluna inaugural, "Adicionar funcionalidade a um objeto" (msdn.microsoft.com/magazine/jj890759), Vogel olha para um aplicativo de gerenciamento de pedidos de vendas, e como o cliente pode adicionar dinamicamente permitida a funcionalidade a um objeto que é necessário. Vogel explica que suas colunas irão apresentar um problema de negócios e discutir algumas soluções alternativas antes de mergulhar, como ele escreve, "uma solução que resolve o problema de forma testável/manutenção, com base em algum padrão de design." De lá, os leitores podem esperar para acompanhar como Vogel constrói o projeto e implementa a solução.
Perguntei-me de Vogel, por que ele queria se concentrar especificamente sobre design patterns. Sua resposta:
"Continuar a trabalhar com programadores que estão a tentar resolver o '-sadas que endereço de padrões de design: Reusabilidade, Manutenibilidade, extensibilidade, testabilidade. Mas esses desenvolvedores não olham para as soluções já existentes que fornecem padrões de projeto, porque eles não vêem o design patterns como fontes de inspiração útil ou direção. Eles vêem padrões como sendo mais parecido com camisa: um cara gritando com você que "você está fazendo isso errado!' Esta situação é agravada por muitos dos exemplos de padrão de projeto ser sobre coisas que a maioria dos desenvolvedores de aplicativos de negócios nunca iria construir — editores, por exemplo.
"Quero mostrar que padrões de design devem ser parte do kit de ferramentas do desenvolvedor como design de banco de dados relacional ou programação estruturada. Padrões de design são, para mim, todos sobre a mudança de 'pensar no código de procedimento' para "pensando em objetos". Esta coluna deve demonstrar que os padrões de design, como os três níveis de normalização de dados, fornecem respostas muito útil para alguns problemas muito comuns."
Os frutos desse esforço já são visíveis no enérgico volta-e-vem na seção de comentários dos padrões primeiros coluna da prática e estão a moldar a direção de cobertura Vogel hoje. Vogel diz que ele ajustar o design do seu modelo de objeto — apresentado em detalhes em sua coluna de fevereiro, "Design para adicionar funcionalidade para a classe de dados" (msdn.microsoft.com/magazine/jj984634) — com base em convincente argumentos feitos em resposta aos padrões primeiros coluna da prática.
"Enquanto eu estou sempre resistente quando as pessoas discordam de mim, eu tento gerar perguntas que resolverão a discussão de uma forma ou de outra," Vogel diz. "Que me permite sair e procurar as respostas a essas perguntas e aplicar as provas em vez de apenas pisar meus pés ou cair de volta em 'princípios'."
Vogel diz que ele vê vários erros comuns quando se trata de trabalhar com padrões, começando com os desenvolvedores que não conseguem tirar proveito dos padrões onde eles seriam realmente úteis. "Os desenvolvedores acabam gastando tempo reinventar a roda e terminando com uma forma oval, um círculo seria uma escolha muito melhor," diz ele.
Vogel continua observando que conjuntos de ferramentas modernos fazem padrões comuns fáceis de implementar, mas muitos desenvolvedores não estão cientes dos recursos disponíveis. Finalmente, ele diz, os desenvolvedores podem ser executadas no problema de erros de diagnóstico — eles ou entender mal o que destina-se um padrão de design para solucionar ou diagnosticar incorretamente o problema que eles estão tentando resolver.
Nos próximos meses, você pode esperar padrões na Vogel coluna de prática para explorar o padrão observer e como uma variação dele é implementada em SignalR para aplicações de arquitetura baseada na Web e orientada a serviços (SOA). Vogel diz que as colunas vão mostrar como alterar conjuntos de tecnologia pode tornar alguns padrões mais atraente em um ambiente onde o padrão seria, como ele diz, "caso contrário ser Descartado como un-implementable." Também Olhe para um estudo de caso, construído em torno do padrão de decorar.
Você tem um conceito ou padrão que você gostaria de ver Vogel explorar em sua coluna? Me escreva no mmeditor@microsoft.com e deixe-nos saber!
Michael Desmond é o editor-chefe da MSDN Magazine.