Este artigo foi traduzido por máquina.

O programador

.NET com vários paradigmas, Parte 1

Ted Neward

Ao longo dos anos, muitos de nós na comunidade .net tem ouvido falar da “ personas da Microsoft ” para o ambiente do Visual Studio: Einstein (o genius), Elvis (a estrela de rock) e Mort (desenvolvedor “ médio ”). Útil pois essas personas podem ser da Microsoft na tentativa de descobrir com precisão para quem eles estiver construindo Visual Studio e a plataforma Microsoft .net, descobri-los para ser menos útil. Na verdade, eu já vêm perceber que para a grande maioria de ecossistema do .net, os desenvolvedores na maioria das vezes recair em um dos dois camps básicas (e altamente stereotypical):

Desenvolvedores de C++. Este é um desenvolvedor que aprendeu todas as práticas “ boas ” orientado a objeto e procura a criação de modelos de domínio Rich em todas as oportunidades, mesmo quando a gravação de um arquivo em lotes. Se esse desenvolvedor antigo de realmente ter escrito C++ profissionalmente, provavelmente que ela concentra-se na criação de estruturas e abstrações reutilizáveis, até o ponto em que ela provavelmente nunca entregue nada. Como os desenvolvedores podem ser identificados por seu atitude pretentious e são normalmente encontrados vincularem “ padrões ” com pessoas em um esforço vain “ ensinar as massas huddled ruins que simplesmente não entendem o que é a qualidade sem um nome ”.

Desenvolvedores de VB. Este é um desenvolvedor que ouviu todas a hoopla sobre objetos, modelos, procedimentos e tudo o que é sido tossed em torno ao longo dos anos (décadas?) e firmemente e peremptoriamente adotou uma atitude “ farei tudo, desde que o código é fornecido ”. Na verdade, esse desenvolvedor então enfoca quando apresentado com uma solicitação para adicionar um novo botão para um formulário existente, ele irá regravar a coisa toda desde o início do código de entrega. Esses desenvolvedores são indicados para a sua atitude “ não quero saber como ele funciona, apenas me dizer o que fazer ” de marca registrada e geralmente são encontradas copiando o código do Google e colá-las em seus programas (às vezes aleatoriamente) até que ele funciona.

Antes do início do enorme dos emails de ódio, let’s Destaque o óbvio: Esses são os estereótipos brutos e, certamente, não estou apontando dedos para qualquer pessoa ou indicando que o grupo é melhor do que o outro. (Provenientes do primeiro grupo, mas serei o primeiro a ocupar braços contra qualquer pessoa que quiser sugerem que esse torcida é alguma forma superior).

Eu Observe a existência desses dois grupos, principalmente porque esse próximo conjunto de colunas está prestes a ser destinados mais especificamente o último — os desenvolvedores de VB – que ainda não passou muito tempo pensando sobre design de software. No entanto, talvez surpreendente, o que cobrimos devem juros o primeiro grupo da mesma forma, pois com a versão do Visual Studio 2010 e o .NET Framework 4, as coisas tem chegado muito mais complicadas, pelo menos no espaço da linguagem. Se os programadores de trabalho para ter uma chance na criação software (ou estendendo software já criado) na década próxima sem torná-lo em uma poça gigante de silício parafernália, é porque eles obtêm um bom aterramento no design multi-paradigm ou o que eu já se deparou chamar multiparadigmatic de programação. (Sim, é um título pretentious. Raízes do C++ My são exibidos — prosseguiu me.)

Design multi-Paradigm

O design de termo multi-paradigm (e o conceito de se dizer que o autor de um único) teve origem no livro “ Multi-Paradigm Design para C++ ” por James O. Coplien (Addison-Wesley Professional, 1998). Com base na última parte do título, é relativamente fácil de adivinhar quais os dois camps livro inicialmente direcionado. No entanto, a linguagem tornou possível quase ao lado de um ponto;Ponto do Coplien ainda resonates, uma década mais tarde:

Um perigo oculto … é que o termo “ orientado a objeto ” se tornou um sinônimo para a “ BOM ”. … No mercado de hoje, você pode localizar o rótulo de “ objeto ” anexado a cada paradigma imaginável. Isso leva a ambientes de design híbrido que se baseiam em um anexo para o passado, geralmente contam com um desejo de aproveitar os investimentos em tecnologias e os antigos métodos. E a maioria desses ambientes é chamada apenas de “ orientado a objeto. ” Uma responsabilidade de tais métodos combinados é que eles obscurecer alguns dos princípios do design orientado a objeto, substituindo o Princípios de outros métodos em seu local central. Essas combinações confusos das técnicas de design podem levar a arquitetura de desastres. … Manutenção se torna difícil, enfraquece a estrutura geral e leva uma enorme de energia para manter o sistema viável.

Mas objetos puros não são a resposta seja. Paradigmas perfeitamente boas tem sido marginalized pela atenção orientado a objeto. O tom em ambientes de desenvolvimento contemporâneo é que ninguém pode ser detectada morto usando procedimento de Decomposição, mesmo para um lote de rotina de classificação, objetos de alguma forma devem ser criados à solução. Isso nos leva a projetos nos quais os pinos quadrados foram forçados até os buracos arredondados.

O histórico de ciência da computação é poluído utópico soluções para problemas, começando quase de seu início: repetidas tentativas de criar um único modo de exibição geral ou uma abordagem para a solução de problemas nos deu ao montadores primeiro e, em seguida, compiladores e ao longo do processo gerado um setor cottage inteiro em “ sucks seu idioma e Eis o porquê. ” Os profissionais mais pragmáticos ignorados e disse que “ quando tudo o que é um martelo, tudo o que parece um prego. ” Como idiomas cresceram mais complexos, alguma forma podemos perdido visíveis do fato de que uma ferramenta de fato poderia ser usada para diversos propósitos.

Para mim, enlightenment sobre esse assunto obtido ao Anders Hejlsberg ouvir falar sobre o c# 3. 0 no Summit linguagens dinâmicas em Redmond há alguns anos. Ele apontado que c# foi incorporando algumas idéias de outros idiomas e disse algo para o efeito de “ idiomas são perder suas classificações. Mais poderá dizemos que um idioma é apenas uma linguagem orientada a objeto, ou apenas uma linguagem dinâmica, pois assim, muitos deles emprestar de muitas idéias diferentes. ”

Seus comentários ecoados palavras do Coplien antes de uma década: “ C++ vai além [além dos paradigmas precedido, como a modularidade, abstract os tipos de dados, procedimentos e as estruturas de dados] para suporte a procedimentos, modular, baseada em objeto, e orientada a objeto e programação genérica em pé de igualdade. ”

C# vai ainda mais, a incorporação conceitos funcionais na versão 3. 0 e conceitos dinâmicos na versão 4. 0. Visual Basic tinha dinâmicos há muito tempo (embora normalmente era scorned) e graças ao objetivo da Microsoft “ paridade de linguagem ” entre ele e o c#, oferece suporte para os mesmos recursos. Sem esses paradigmas de linguagem adicionais à espreita sob a superfície, soluções, como o LINQ são mais difíceis e forçar o desenvolvedor dependem de outros mecanismos (como, por exemplo, geração de código, que é um aspecto interessante de metaprogramming — mais informações sobre isso posteriormente) capturar a semelhança de núcleo de um sistema de trabalho de forma a “ herda da classe base ” não foi possível.

Esse é o núcleo do qual, vamos explorar: os zealots orientado a objeto do mundo têm insisti há anos que herança representa a melhor abordagem para reutilizar o código. (Isso é o motivo classes não são marcados como “ lacradas ” [C #] ou [VBA] “ NotInheritable ” por padrão.) E ainda assim, podemos realmente não substituem métodos da classe base quando herdadas da classe Form em WinForms ou do asp.NET;em vez disso, nós fornecemos os delegados para invocação. Por que não basta substituir? Por que tirar a ocorrência (pequenos que ele possa ser) de invocação de delegado? Por que code-behind vão de um modelo de herança para um modelo com base em classes parciais? Por que tem em todos os métodos de extensão?

As respostas para cada uma dessas questões podem ser (e tem sido!) explicada na terminologia orientado a objeto, mas o motivo pelo qual subjacente permanece o mesmo: facilmente, nem tudo pode ser representado em construções de design clássicas de objeto. Tentando encontrar as partes comuns de código e colocá-los juntos em uma construção de primeira classe única (seria mantenha a tecla a programação orientada a objeto é uma classe e programação estrutural poderia considerar dados de uma estrutura e programação funcional manteria uma função, e assim por diante) é o objetivo do design de software e de outras maneiras de nós pode variar as partes do código que precisa de variação, quanto mais podemos escrever sistemas que meteorológico as winters adversos de clientes chamando com “ apenas uma pequena pouca coisa esqueci de lhe dizer... ”

Como exercício, considere o seguinte: O .NET Framework 2. 0 introduziu os genéricos (tipos parametrizados). Por quê? Da perspectiva do design, o que a objetivo servem? (E para o registro, as respostas do “ IT nos permite ter coleções fortemente tipada ” não têm o ponto — o Windows Communication Foundation usa genéricos amplamente, claramente de maneiras que não são coleções de trata apenas de tipo seguro.)

Poderá entrar em que a próxima parte.

Não inativo (ou concluído) ainda!

Claramente há muito, muito mais ainda a ser dito sobre este assunto, cada um dos paradigmas presentes no .NET Framework merece alguma exploração e a explicação, completo com código, se for esta primeira parte para tornar a qualquer tipo de detecção para o desenvolvedor de trabalho. Essas partes subseqüentes irão estar vindo, travar até lá. Quando pronto, eu espero (e pensar) você terá um giro inteiro das melhores ferramentas de design para construção de check-out de BOM (e por que eu quero dizer well-abstracted, passível de manutenção, extensível e utilizável) software.

Mas por ora, concentre-se em examinar os designs atuais que você está trabalhando com e ver se é possível identificar as partes do projeto usam alguns dos conceitos de alto nível de cada um desses paradigmas diferentes – Obviamente, as partes do objeto será relativamente fácil de reconhecer, portanto, se concentrar em alguns dos outros. Quais partes da sua base de código (ou o .NET Framework) são os procedimentos de natureza ou metaprogrammatic?

A propósito, se houver um tópico específico que você deseja ver exploradas, não hesite em me que uma observação e verá sobre tentando agendá-la em uma vez que fizemos com essa determinada série para soltar. Uma maneira bastante real, é a coluna, afinal de contas.

Codificação feliz!

Ted Neward é uma entidade de segurança com Neward &Associa uma empresa independente especializado em sistemas da plataforma Java e empresa do .NET Framework. Ele escreveu mais de 100 artigos, é um MVP de c#, palestrante da INETA e autor ou co-autor de diversos livros, incluindo o disponível em breve “ Professional F # 2. 0 ” (Wrox). Ele consulta e mentors regularmente. Entrar em ted@tedneward.com de e leia seu blog em blogs.tedneward.com de .