El programador políglota

.NET multiparadigmático, Parte 3: programación de procedimientos

Ted Neward

Ted Neward El mes pasado, el ejercicio de diseño de software como una de las similitudes y variabilidad superado como el centro del panel de discusión (consulte msdn.microsoft.com/magazine/gg232770 de ). Nos deja con la idea de que el lenguajes de software como C# y Visual Basic ofrecen paradigmas diferentes para representar estos conceptos de similitudes y variabilidad a lo largo de diferentes dimensiones, y que el núcleo de diseño multiparadigmatic en las demandas del dominio con las funciones del idioma de la asignación.

Este mes, Comenzaremos examinando una de las instalaciones anteriores de lenguajes de programación “ programación procedural ”, en ocasiones también se conoce como “ programación estructurada, ”, aunque son algo ligeramente diferentes. Aunque normalmente considerada como “ antiguo escuela ” y, por tanto, obsoleta y no sirve de nada en el diseño de software moderno, el paradigma de diseño del procedimiento todavía aparece en un sorprendente número de posiciones.

Procediendo de IT, School antiguo

Para los que no estaban activos cuando la programación estructurada surgido como un término de nuevo, el principio básico era poner definition (estructura) alrededor del código que se está escribiendo, en una práctica, esto significaba “ puntos de entrada único ” y “ puntos de salida único ” para los bloques de código que se escriben en el ensamblado en el momento. El objetivo aquí era bastante sencillo, en retrospectiva: colocar algunas abstracciones de nivel superior alrededor de los bits repetitivas de código que se han flotantes.

Pero con frecuencia, estos comandos (procedimientos) necesitan alguna variación a ellos si se encontraran en absoluto útiles y parámetros: entrada pasado al procedimiento para modificar su ejecución, se incluye como parte del enfoque, en primer lugar de manera informal (“ pasa el carácter que desea mostrar en el registro AX ”), a continuación, formalmente (como parámetros de funciones, como en C / C++ / C# y Java o Visual Basic y similares). Procedimientos de calcular con frecuencia algún tipo de valor devuelto, en ocasiones, derivada de la entrada pasada, a veces, simplemente, para indicar éxito o fracaso (tal como se muestra en el caso de escribir datos en un archivo o base de datos);También existen especificados y controladas por el compilador.

Sin embargo, todo esto es un tema de solución para la mayoría de los lectores. No es lo que le pregunta el enfoque multiparadigm de nosotros rehash historial, que examina otra vez a través del objetivo del análisis de compatibilidad. ¿Lo que, en concreto, es que se generalizó en el enfoque del procedimiento, y cómo se introducen cambios? Una vez que se identifica la variabilidad, ¿qué tipo de cambios es, positivo o negativo?

Con gafas de similitudes y variabilidad en, el paradigma del procedimiento da como resultado de secretos interesantes: Se recopila la uniformidad en los procedimientos, que básicamente se denominan bloques de código que se puede llamar desde cualquier contexto determinado. (Lenguajes procedimentales dependen en gran medida “ ámbito ” para aislar el trabajo dentro del procedimiento fuera del contexto que lo rodea.) Una forma de introducir variabilidad en el procedimiento es de parámetros (que indica cómo procesar el resto de los parámetros, por ejemplo), que pueden tener la variabilidad positiva o negativa, dependiendo de cómo se escribe el propio procedimiento. Si el origen de dicho procedimiento no está disponible o no debe modificarse por alguna razón, todavía se puede tenía variabilidad mediante la creación de un nuevo procedimiento que cualquiera llama al procedimiento anterior, o no, dependiendo de si se desea la variabilidad positiva o negativa.

Procedimientos de saludo

En esencia, el procedimiento proporciona comportamiento común, que puede variar en función de entrada. E, irónicamente, el primer ejemplo que observamos del paradigma del procedimiento se encuentra en el primer ejemplo que consulte alguna vez la mayoría de los programadores de Microsoft .NET Framework:

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

En la aplicación WriteLine, los desarrolladores de pasar una cadena de formato que describe no sólo lo que desea imprimir a cabo, pero la forma de impresión, incluyendo los comandos formateador de contenido dentro de los marcadores de recambio, así:

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

La implementación de WriteLine es un caso práctico interesante, que difiere ligeramente de su predecesor de antigüedad, printf de la biblioteca estándar de C. Recuerde que printf tuvo un tipo similar de la cadena de formato utilizando diferentes marcadores de formato y se escribe directamente en la consola (la secuencia STDOUT). Si un programador desea escribir el resultado con formato en un archivo o en una cadena, tenían que se va a invocar diferentes variaciones de printf: fprintf en el caso de un archivo de salida o sprintf en el caso de una cadena. Sin embargo, el formato real de la salida era normal y las bibliotecas de tiempo de ejecución C a menudo aprovecharon este hecho mediante la creación de una sola función de formato genérica antes de enviar los resultados para el destino final, un ejemplo perfecto de compatibilidad. Sin embargo, este comportamiento de formato se considera “ cerrado ” para el desarrollador de C de la media y no se pueden extender. .NET Framework tiene un paso más allá de eso, que ofrece a los programadores la oportunidad de crear nuevos marcadores de formato si se pasa la responsabilidad a los objetos pasados a WriteLine después de la cadena de formato. Si el objeto implementa la interfaz IFormattable, le ha proporcionado la responsabilidad para averiguar el formato de marcador y devuelve una cadena con el formato apropiado para su procesamiento.

También se puede ocultar la variabilidad detrás de otros lugares en el enfoque del procedimiento. Al ordenar los valores, el procedimiento qsort (una implementación Quicksort) necesita ayuda para saber cómo comparar dos elementos para determinar cuál de ellas era mayor o menor que el otro. Para requerir a los desarrolladores escribir sus propios qsort de contenedores, el mecanismo de variabilidad tradicionales, cuando el original estaba untouchable: Would have sido demasiado complicado y difícil. Afortunadamente, el paradigma del procedimiento que ofrece un enfoque diferente, una variación del tiempo de compilación de lo que sería más adelante se convierten en conocido como inversión de control: El programador C que se pasa un puntero a una función, qué qsort invocado como parte de su funcionamiento. Este parámetro, en esencia una variación del enfoque de parámetros como la variabilidad, que ofrece un enfoque de la variabilidad de extremo abierto, en que se podría utilizar cualquier procedimiento (por lo tanto, cuánto tiempo cuando se cumplen los parámetros y devolver las expectativas de tipo). Aunque son escasos en primer lugar, con el tiempo expresión del paradigma de esta se convirtió en más y más habituales, por lo general en la etiqueta general de “ devoluciones de llamada ”en el momento en que se lanzó Windows 3.0, era una práctica de núcleo aceptados y sea necesario para escribir programas de Windows.

Servicios de saludo

Más Curiosamente, el lugar donde el paradigma del procedimiento ha alcanzado el éxito de más extendido (si nos blithely omitir la increíble éxito y la ubicuidad de la biblioteca estándar de C, por supuesto) está en el territorio orientada a servicios. (En este caso, uso el término “ servicio ” significa un conjunto más amplio de software, en vez de la tradicional restringir la vista de sólo WS-* o SOAP/WSDL [WSDL]-en función de servicios.REST-based implementaciones, así como las implementaciones de RSS/Atom ajusten mucho a la misma definición.)

Función más allá de la documentación que aparece en msdn.com , como “ principios de orientada a servicios diseño ” (msdn.microsoft.com/library/bb972954 de ), servicios siguen cuatro principios básicos:

Los límites son explícitos.
Los servicios son autónomos.
Servicios comparten esquema y contrato, no de clase.
Servicio de compatibilidad se basa en la directiva.

Estos principios, tal vez sin intención de que lo haga, refuerzan la naturaleza de los servicios como la que pertenece el paradigma del procedimiento de diseño más a la orientada a objetos. “ Límites son explícitos ” refuerza la noción de que el servicio es una entidad independiente y distinta del sistema de invocarlo.Esta vista se refuerza mediante la noción que “ servicios son autónomos ” y, por tanto, distintos entre sí, lo ideal es que incluso en el nivel de administración de infraestructura. “ Servicios comparten esquema y contrato, no de clase ” que se refiere a la noción de que los servicios se definen en términos de los parámetros enviados a los mismos, expresado como construcciones de XML (o JSON), tipos de tiempo de ejecución no es específica de una plataforma o lenguaje de programación determinado. Por último, “ el servicio de compatibilidad se basa en la directiva ” sugiere que servicios deben ser compatibles en función de las declaraciones de la directiva, que proporcionan más de un contexto de la invocación, esto es algo que tradicionalmente ha asumido el paradigma del procedimiento desde el entorno circundante y, por tanto, no es necesario definir explícitamente.

Los desarrolladores pueden ser rápidos destacar que, en servicios clásicos de WSDL, es más difícil de crear la variabilidad debido a que el servicio está relacionado con la definición de esquema del tipo de entrada. Pero esto es sólo para las más básicas (o generative de código) de servicios, los tipos de entrada y el resultado puede ser (y con frecuencia son) vuelve a utilizar en definiciones de servicios. De hecho, si la noción de servicio se expande para incluir los sistemas basados en REST, a continuación, el servicio puede aceptar cualquier número de tipos diferentes de los tipos de entrada: toma, esencialmente, los parámetros del procedimiento en una función de extremo abierta y interpretativa generalmente no se puede ver en procedimientos estáticamente con tipo tradicionales y tienen un comportamiento diferente, lo que genera la variabilidad dentro de ese servicio perfectamente para las partes delanteras de nuevo. Parte de ese comportamiento, por supuesto, deberá ser validational por naturaleza, ya que no siempre será adecuado para cada tipo de datos que se pueden producir en el URL del servicio (su nombre).

Cuando servicios se ven a través del objetivo de un sistema de mensajería, como, por ejemplo, BizTalk, ServiceBus o algún otro bus de servicios empresariales, mantiene el aspecto del procedimiento, aunque ahora se sitúa la variabilidad toda con los mensajes que se pasa, porque los mensajes transmiten la totalidad del contexto de llamada, ni siquiera el nombre del procedimiento para llamar a está presente. Esto también implica que el mecanismo de variabilidad en la que se ajuste otro procedimiento en una nueva, presentación o la restricción de variabilidad de esta forma, ya no está presente, ya que normalmente no controlan cómo se pasan los mensajes de todo el bus.

Los siguientes con el proceso

El paradigma del procedimiento muestra algunas de las dimensiones de similitudes y variabilidad más antiguas:

Nombre y el comportamiento. Los nombres de transmiten un significado. Podemos utilizar la compatibilidad de nombre a los elementos de grupo (por ejemplo, los procedimientos o métodos) que tienen el mismo significado. De hecho, lenguajes “ modernos ” nos han permitido a capturar esta relación más formalmente, ya que permite que dispone de distintos métodos utilizan el mismo nombre, siempre que varían en el número y tipos de parámetros.Éste es el método de sobrecarga. C++, C# y Visual Basic también pueden sacar partido de los métodos con el nombre apropiado mediante la creación de métodos cuyos nombres están bien definidas en función de álgebra.se trata de la sobrecarga de operadores. F # toma esto aún más, ya que permite a los desarrolladores crear operadores nuevos.
Algoritmo. Los algoritmos no son los cálculos matemáticos justo, pero repetidos en su lugar los pasos de ejecución. Si el sistema completo (en lugar de las capas individuales) se ven en un principio formulario desplegable, fragmentos de código/proceso de interesantes, casos de uso, de hecho, comienzan a aparecer las familias de ese formulario. Una vez identificados estos pasos (procedimientos), pueden formar familias alrededor de la variabilidad en función de funcionamiento en diferentes tipos de datos o los parámetros del algoritmo, el procedimiento. En C#, F # y Visual Basic, estos algoritmos pueden ser varía si se colocan en las clases base, a continuación, varía en función de heredar de la clase base y reemplazar el comportamiento de la base;Éste es el método de reemplazo. También se puede personalizar el comportamiento algorítmico dejando parte de ese comportamiento no se especifica y se pasan en;Esto es utilizar delegados como las devoluciones de llamada o de inversión de control.

Una nota final antes de resumir este medio. El paradigma del procedimiento es posible que no se alineen uno a uno con el mundo orientada a servicios;de hecho, muchos expertos de la arquitectura orientada a servicios y los defensores se rechazará incluso la asociación más pequeña que el paradigma del procedimiento, por miedo es dicha asociación tardará algún modo el brillo de su interés personal. Aparte de las directivas, el servicio clásico, ya sea un RESTful uno o una SOAP/WSDL basada en una, lleve una sorprendente semejanza con el paradigma clásico de procedimiento. Como resultado, utilizando el mismo análisis de compatibilidad durante el diseño del servicio de ayuda a crear un nivel aceptable de granularidad, aunque los diseñadores deben tener cuidado para asegurarse de que la exploración transversal (supuesta) de la red para ejecutar el servicio en ubicación del host servicio de no blithely pasarán por alto. En particular, implementaciones de ingenua de los servicios que se utiliza el paradigma del procedimiento pueden intentar utilizar el enfoque “ pasar una devolución de llamada ” de variabilidad y mientras éste no es totalmente una idea terrible, podría representar un problema de rendimiento o el cuello de botella importante.

En este momento, el paradigma del procedimiento que todavía aparezca en una gran cantidad de lo que hacemos, pero ha sido que encuentren dentro de la superficie de ocultación de los desarrolladores con un nombre que se supone. Nuestra siguiente asunto, la orientación a objetos, no dispone de ninguna excusa tal, es el perky saliente, “ oye, vienen mirar me! ” más jóvenes hermana su relacionado del procedimiento anterior moody, melodramatic y a menudo pasan por alto. En la parte del próximo mes, comenzaremos a analizar las dimensiones de similitudes y variabilidad de los objetos y de lo que encontremos puede resultar sorprendente.

Mientras tanto, como un ejercicio intelectual, convierta al gaze alrededor de las diversas herramientas que utilice y identifica cuál de ellos utilizar tácticas fundamentalmente del procedimiento. (Sugerencia: Dos de ellas son herramientas que se utilizan todos los días al escribir software: el compilador y MSBuild, el sistema de compilación ocultado inmediatamente detrás del botón de la compilación en Visual Studio.)

Y, como siempre, felices programas.

Ted Neward es un principal con Neward & Asocia una empresa independiente especializado en la empresa de Microsoft .NET Framework y los sistemas de la plataforma Java. Ha escrito más de 100 artículos, es un ponente INETA y de los MVP de C# y ha creado y coautor de libros de una docena, como “ Professional F # 2.0 ” (Wrox, 2010). También consulta y mentors con regularidad. Ponerse en ted@tedneward.com con preguntas o solicitudes de consultoría y leer su blog en blogs.tedneward.comde .

Gracias al siguiente experto técnico para este artículo: Anthony verde