O programador

.NET com vários paradigmas, Parte 3: Programação de procedimentos

Ted Neward

Ted Neward No mês passado, o exercício de design de software como um dos aspectos comuns e variabilidade significava como a peça central da discussão (consulte msdn.microsoft.com/magazine/gg232770 de ). Ele nos deixado com a idéia de que o software de linguagens como c# e Visual Basic oferecem paradigmas diferentes para representar esses conceitos de semelhança/variabilidade ao longo de diferentes dimensões e que a essência do design multiparadigmatic está sendo emparelhamento de demandas de domínio com os recursos da linguagem.

Neste mês começaremos examinando-se um dos recursos mais antigos de programação de idiomas, “ programação procedimento ”, às vezes também conhecida como “ programação estruturada ”, embora as duas são um pouco a pouco diferentes. Embora geralmente visto como “ antigo da escola ” e, portanto, desatualizada e inúteis no design de software moderno, o paradigma de design de procedimento ainda aparece em um número surpreendente de casas.

Continuando IT, School antigo

Para aqueles que não estavam ativas quando surgiu de programação estruturada como um novo termo, foi a principal filosofia colocar definition (estrutura) em todo o código que está sendo escrito — em um nível prático, isso significava “ pontos de entrada única ” e “ pontos de saída única ” para os blocos de código que está sendo escrito em conjunto no momento. O objetivo aqui era muito simples em retrospecto: coloca algumas abstrações de nível mais alto em torno de bits de repetitivas do código que eram circulando.

Mas com freqüência, esses comandos (procedimentos) necessária alguma variação para eles, caso venham a ser útil em todos os parâmetros e — entrada passada para o procedimento para variar sua execução — foram incluídos como parte da abordagem, primeiro informalmente (“ passar o caractere que você deseja exibir no registrador AX ”), e em seguida, formalmente (como parâmetros para funções, como em C / C + + / c#/Java/Visual Basic e assim por diante). Procedimentos calcular geralmente algum tipo de valor retornado, às vezes, é derivado de entrada passada, às vezes, simplesmente para indicar êxito ou falha (como no caso de gravar dados em um arquivo ou banco de dados);também são especificados e manipulados pelo compilador.

No entanto, tudo isso é um tópico corretiva para a maioria dos leitores. Não é de nós a abordagem multiparadigm pede rehash histórico, mas para vê-la novamente por meio das lentes de análise de uso comum. O que, mais especificamente, está sendo generalizado na abordagem de procedimento, e como apresentamos variabilidade? É assim que a variabilidade é identificada, o tipo de variabilidade — positivo ou negativo?

Com óculos de variabilidade de semelhança/no, o paradigma do procedimento produz até segredos interessantes: A semelhança é reunida em procedimentos, que, basicamente, são chamados de blocos de código que podem ser chamados a partir de qualquer contexto específico. (Linguagens de procedimento dependem muito “ escopo ” para isolar o trabalho fora do contexto ao redor do procedimento.) Uma maneira de apresentar a variabilidade dentro do procedimento é por meio de parâmetros (que indica como processar o restante dos parâmetros, por exemplo), que podem ter variabilidade positiva ou negativa, dependendo de como o procedimento propriamente dito é gravado. Se a fonte para esse procedimento não está disponível ou não deve ser modificada por algum motivo, variabilidade pode ainda tinha, criando um novo procedimento que seja chama o procedimento antigo ou não, dependendo se a variabilidade positiva ou negativa é desejada.

Procedimentos de saudação

Em essência, o procedimento fornece comportamento comum, que pode variar com base na entrada. E, ironicamente, o primeiro exemplo, vemos do paradigma do procedimento reside no primeiro exemplo que consulte nunca a maioria dos programadores do Microsoft .NET Framework:

Sub Main()
    Console.WriteLine("{0}, {1}!", "Hello", "world!")
End Sub

Na implementação WriteLine, os desenvolvedores passam uma seqüência de caracteres de formato de descrição não só o que imprimir para fora, mas como imprimi-lo, incluindo os comandos de formatador contidos em marcadores de substituição, da seguinte forma:

Sub Main()
    Console.WriteLine("Hello, world, it's {0:hh} o'clock!", Date.Now)
End Sub

A implementação de WriteLine é um estudo de caso interessante, que difere um pouco de sua predecessora antigo, printf da biblioteca C padrão. Lembre-se de que printf levou um tipo similar de seqüência de caracteres de formato usando marcadores de formatação diferentes e gravou diretamente do console (o fluxo STDOUT). Se um programador quisesse gravar a saída formatada em um arquivo ou uma seqüência de caracteres diferentes variações de printf tinham que ser chamada: fprintf no caso de arquivo de saída ou sprintf no caso de uma seqüência de caracteres. Mas a formatação real da saída era comum e bibliotecas de tempo de execução C sempre aproveitaram esse fato através da criação de uma única função genérica de formatação antes de enviar os resultados para o destino final — um exemplo perfeito de semelhança. No entanto, esse comportamento formatação era considerado “ fechado ” para o desenvolvedor médio C e não pôde ser estendido. O .NET Framework tem um passo além disso, oferecendo aos desenvolvedores a oportunidade de criar novos marcadores de formatação, passando a responsabilidade para os objetos passados no WriteLine após a seqüência de caracteres de formato. Se o objeto implementa a interface IFormattable, ele deu a responsabilidade de descobrir o formatação de marcador e retornando uma seqüência de caracteres formatada adequadamente para processamento.

Variabilidade também poderia ocultar atrás de outros locais na abordagem de procedimento. Ao classificar valores, o procedimento qsort (uma implementação rápida) precisava de ajuda para saber como comparar dois elementos para determinar qual deles estava maior ou menor que o outro. Para exigir que os desenvolvedores escrevam seus próprios invólucros em torno de qsort — o mecanismo de variabilidade tradicionais, quando o original estava intocável — seria estive muito complicado e difícil. Felizmente, o paradigma do procedimento oferecida uma abordagem diferente, uma variação inicial do que seria mais tarde tornam-se conhecido como inversão de controle: O desenvolvedor C passado um ponteiro para uma função, qual qsort chamado como parte de sua operação. Isso, em essência uma variação da abordagem parâmetros como variabilidade, oferecida uma abordagem de variabilidade abertas, em que qualquer procedimento (, desde como ela satisfeitas de parâmetro e as expectativas do tipo de retorno) poderia ser usado. Embora raros em primeiro lugar, ao longo do tempo idioma do paradigma para esse se tornaram mais e mais comuns geralmente sob o rótulo geral de “ retornos de chamada ”;Quando o que Windows 3. 0 foi lançado, era uma prática de núcleo aceito e necessário para escrever programas do Windows.

Serviços de saudação

Mais interessante é que o local onde o paradigma do procedimento atingiu o mais difundido êxito (se blithely, podemos ignorar o incrível sucesso e a onipresença da biblioteca C padrão, do curso) está no território orientadas a serviços. (Aqui, usarei o termo “ serviço ” para se referir a um conjunto mais amplo de software, em vez da tradicional restringir o modo de exibição de apenas o WS-* ou SOAP/Web Services Description Language [WSDL]-com base em serviços;Implementações de REST-based, bem como Atom/RSS implementações se encaixam a mesma definição.)

De acordo com a anterior literatura que aparecem em msdn.com , como “ princípios de Service-Oriented Design ” (msdn.microsoft.com/library/bb972954 de ), serviços de obedecem quatro filosofias básicas:

Os limites são explícitos.
Os serviços são autônomos.
Serviços compartilham esquema e contrato, não a classe.
Compatibilidade de serviço é baseada em diretiva.

Esses princípios, talvez sem intenção de fazer isso, reforçam a natureza dos serviços como pertencentes ao paradigma do procedimento de design mais àquele orientado a objeto. “ Os limites são explícitos ” reforça a noção de que o serviço é uma entidade separada e distinta do sistema chamandoEste modo de exibição é reforçado pela noção que “ os serviços são autônomos ” e, portanto, diferente de um outro, o ideal é que, mesmo em um nível de gerenciamento de infra-estrutura. “ Serviços compartilham esquema e contrato, não a classe ” fala com a noção de que os serviços são definidos em termos de parâmetros enviados a elas, expresso como construções de XML (ou JSON), tipos de tempo de execução não específicas de uma determinada linguagem de programação ou plataforma. Por fim, “ compatibilidade Service é baseada na política ” sugere que serviços devem ser compatíveis com base em declarações de diretiva, que fornecem mais de um contexto em torno da chamada — isso é algo que o paradigma do procedimento historicamente assumiu a partir do ambiente e não como tal, é necessário definir explicitamente.

Os desenvolvedores podem ser rápidos de destacar que nos serviços baseados em WSDL clássicos, é mais difícil criar variabilidade, como o serviço está vinculado à definição de esquema do tipo de entrada. Mas isso vale apenas para os mais básicos (ou generative de código) dos serviços — tipos de entrada e o resultado pode ser (e freqüentemente estão) reutilizados nas definições de serviço. Na verdade, se a noção de serviço é expandida para incluir sistemas baseados em REST, em seguida, o serviço pode aceitar qualquer número de tipos diferentes de tipos de entrada — basicamente, os parâmetros para o procedimento estiver fazendo em uma função de extremidade aberta e interpretive geralmente não é vista nos procedimentos digitados estaticamente tradicionais — e se comportam de forma diferente, trazendo a variabilidade dentro desse serviço justamente para o primeiro novamente. Alguns desse comportamento, é claro que, precisará ser validational por natureza, porque o URL do serviço (seu nome) não será sempre apropriado para cada tipo de dados que podem ser gerados por ele.

Quando serviços são vistos por meio das lentes de um sistema de mensagens, como o BizTalk, ServiceBus ou algum outro Enterprise Service Bus, ainda mantém a proporção de procedimento, que agora a variabilidade inteira é posicionado com as mensagens que estão sendo passadas ao redor, porque as mensagens de transportar a totalidade do contexto de chamada — nem mesmo o nome do procedimento de chamar está presente. Isso implica que o mecanismo de variabilidade pelo qual podemos dispor outro procedimento em um novo — ou apresentando a restrição de variabilidade em fazê-lo — não está mais presente, porque nós geralmente não controla como as mensagens são passadas em torno do barramento.

Bem-sucedidos com prosseguindo

O paradigma do procedimento demonstra algumas das dimensões de semelhança/variabilidade mais antiga:

O nome e comportamento. Nomes de transmitam um significado. Podemos usar a semelhança de nome de grupo de itens (como procedimentos/métodos) que possuem o mesmo significado. Na verdade, linguagens “ modernas ” têm permitiu capturar esse relacionamento mais formalmente, permitindo que os nós têm diferentes métodos de usar o mesmo nome, desde que eles variam em número e/ou tipos de parâmetros;Este é o método de sobrecarga. C++, c# e Visual Basic também podem aproveitar dos métodos nomeados adequadamente com a criação de métodos cujos nomes são bem entendidos, com base em álgebra;Esta é a sobrecarga de operador. F # leva isso ainda mais, permitindo que os desenvolvedores criem novos operadores.
Algoritmo. Algoritmos não são cálculos matemáticos apenas mas repetidas em vez disso, as etapas de execução. Se o sistema inteiro (em vez de camadas individuais) for exibidas em um superior forma suspensa, um interessante fragmentos de código do processo — use os casos, de fato — começam a surgir famílias nesse formulário. Após a identificação dessas etapas (procedimentos), as famílias podem se formar em torno de variabilidade com base em como o algoritmo/procedimento opera em diferentes tipos de parâmetros de dados. No c#, F # e no Visual Basic, esses algoritmos podem ser variados, colocando-as em classes base e modificados por herança da classe base e a substituição comportamento da base de;Este é o método de substituição. Comportamento algorítmico também pode ser personalizado, deixando a parte desse comportamento não for especificado e passado;Isso é usar delegados como inversão de controle ou retornos de chamada.

Uma última observação antes de concluirmos essa informação. O paradigma do procedimento pode não alinhados-para-um com o mundo orientado a serviços;Na verdade, muitos defensores da arquitetura orientada a serviços e proponentes rejeitará até mesmo a menor associação ao paradigma do procedimento, por fear que tal uma associação de alguma forma levará o brilho de seu interesse especial. Reserve política, o serviço de clássico — seja ela uma RESTful um ou um/WSDL baseados em SOAP um — é responsável por uma elegante semelhança com o paradigma do procedimento clássico. Como resultado, usando a mesma análise de uso comum durante a criação do serviço de ajuda a criar um nível aceitável de granularidade, embora os designers devem tomar cuidado para garantir que o percurso (suposto) de rede para executar o serviço do host de serviço local não blithely ignorado. Em particular, ingênuas implementações de serviços que usam o paradigma do procedimento podem tentar usar a abordagem “ passar um retorno de chamada ” à variabilidade e enquanto isso não é inteiramente uma idéia terrível, ele pode representar um grande problema de desempenho ou afunilamento.

Até hoje, o paradigma do procedimento ainda é exibida ao longo do que fazemos muito, mas foi à espreita sob a superfície, ocultação de desenvolvedores em um nome assumido. Tem de nosso próximo assunto, orientação a objetos, não há tal desculpa — é o perky, de saída “ Ei, venha me ver! ” mais jovem irmã para seu irmão de antigo procedimento moody, melodramatic e muitas vezes ignorados. Na parte do próximo mês, vamos começar analisando as dimensões de semelhança/variabilidade dos objetos e alguns de nós encontrar pode ser surpreendente.

Nesse ínterim, como um exercício de intelectual, converta seu olhar em volta as várias ferramentas que você usa e identificar qual deles usar táticas fundamentalmente procedimentos. (Dica: Duas delas são ferramentas que você utiliza diariamente durante a gravação de software: o compilador e o MSBuild, o sistema de compilação imediatamente ocultado por trás do botão de compilação no Visual Studio.)

E, como sempre, a codificação feliz!

Ted Neward é uma entidade de segurança com Neward & Associa uma empresa independente especializado em sistemas de plataforma de Java e enterprise do Microsoft .NET Framework. Ele escreveu mais de 100 artigos, é um palestrante da INETA e de MVP de c# e tem autor e co-autor de livros de uma dúzia, incluindo “ Professional F # 2. 0 ” (Wrox 2010). Além disso, ele consulta e mentors regularmente. Entrar em ted@tedneward.com de com perguntas ou solicitações de consultoria e leia seu blog em blogs.tedneward.comde .

Meus agradecimentos aos seguinte especialista técnico para revisar este artigo: Anthony verde