El programador de Trabajo. Multiparadigmático. NET, parte 1. Microsoft. NET Framework, C # y Visual Basic

Ted Neward

Con los años, muchos de nosotros en la comunidad NET, hemos oído hablar de Microsoft, "personas" para el entorno de Visual Studio: Einstein (el genio), Elvis (la estrella de rock), y Mort (el "promedio" de desarrollo). Tan útil como estos personajes podrían ser de Microsoft, para tratar de averiguar con precisión para los que están construyendo Visual Studio y Microsoft. NET, he encontrado que son menos útiles. De hecho, me he dado cuenta, de que para la gran mayoría de los ecosistemas NET, los desarrolladores en su mayoría pertenecen a uno de los dos básicos (y muy estereotipados) campamentos.

El C + + Developer. Este son los desarrolladores, que aprendieron todas las "buenas" prácticas orientadas, a objeto, y buscan construir ricos modelos de dominio, en cada oportunidad, incluso cuando se escribe un archivo por lotes. Si estos desarrolladores, tienen la experiencia suficiente, para escribir, C + + profesionalmente, es probable que se centró en la construcción de marcos y abstracciones reutilizables, hasta el punto que nunca probablemente han enviado nada. Estos desarrolladores, pueden ser identificados por su actitud pretenciosa, y se encuentran a menudo citando a "patrones", a la gente en un vano esfuerzo por "educar a los pobres masas apiñadas que simplemente no entienden lo que es la calidad"

El desarrollador de VB. Este es el desarrollador que escucharon todos los alboroto acerca de los objetos, plantillas, procedimientos, y todo lo que ha sido rechazados en todas partes en los últimos años (¿décadas?), y tienen la firmeza y determinación,  adoptando un "Haré cualquier cosa para siempre y cuando el código de buques, de "actitud". De hecho, esta empresa desarrolladora, es tan centrada en el envío de código, que cuando se presenta una solicitud para añadir un nuevo botón, a un formulario existente, ¿que va a reescribir todo desde el principio?. Estos desarrolladores, son conocidos por su marca "no me digas cómo funciona, sólo dime qué hacer", actitud, y a menudo se encuentran fuera de extracción de código de Google, y pegarlo en sus programas (a veces al azar) hasta que funcione.

Antes de la avalancha de mensajes, de odio, comienza, vamos a señalar lo obvio: se trata de estereotipos brutos, y yo ciertamente no estoy señalando con el dedo a nadie, ni lo que implica que ninguno de los grupos es mejor, que el otro. (Vengo del primer grupo, pero voy a ser el primero en tomar las armas contra cualquier persona que quiera sugerir, que esa gente es de alguna manera superior.)

Tomo nota de la existencia, de estos dos grupos en gran parte porque esta próxima serie de columnas, que va a estar dirigidas, más específicamente a este último el VB, desarrolladores, que no ha pasado mucho tiempo pensando en el diseño de software. Pero, tal vez sorprendentemente, lo que debe cubrir el interés del primer grupo también, porque con el lanzamiento de Visual Studio 2010, y NET Framework 4, las cosas han vuelto mucho más complicadas, al menos en el espacio del lenguajes. Si los programadores de trabajo, van a tener alguna oportunidad en el diseño de software (o programas, se extiende ya a los diseñados) en la próxima década, sin lo que lo convierte en un charco gigante de baba de silicio, será porque reciben una buena formación, en diseño multi-paradigma, o lo que he venido a llamar a la programación Multiparadigmática.

(Sí, es un título pretencioso. Mi raices C + +, están mostrando un demandante.)

Multi-Paradigma de diseño

El término diseño multi-paradigma, (y el concepto, si se puede decir que tienen un solo autor), se originó en el libro "El diseño multi-paradigma para C + +" de James O. Coplien (Addison-Wesley Professional, 1998). Basado en la última parte del título, es relativamente fácil de adivinar cuál de los dos campamentos del libro previsto inicialmente. Sin embargo, el idioma que resultó ser casi fuera de lugar, y punto Coplien todavía resuena, una década más tarde:

Uno de los peligros ocultos ... es que el término "orientado a objetos" se ha convertido en un sinónimo de "bueno". ... En el mercado actual, usted puede encontrar el "objeto," etiqueta de cada paradigma, se pueda imaginar. Esto nos lleva a los entornos de diseño híbridos, que se basan en un apego al pasado, por lo general con el apoyo de un deseo de construir sobre las inversiones en los viejos métodos y tecnologías. Y la mayoría, de estos entornos son llamados "orientado a objetos." Una responsabilidad de tales métodos combinados, es que ocultar algunos de los principios fundamentales del diseño orientado a objetos, la sustitución de los principios de otros métodos en su lugar. Estas combinaciones confusas de las técnicas de diseño pueden conducir al desastre arquitectónico. ... De mantenimiento se hace difícil, la estructura general se debilita, y se necesita una tremenda energía para mantener el sistema viable.

Pero los objetos puros, no son la respuesta, ya sea. Perfectamente bien por paradigmas han sido marginados por una campaña orientada a objetos. El tono en las tiendas de desarrollo contemporáneo, es que nadie sería atrapado muerto con la descomposición de procedimiento, incluso para un lote de clasificación de rutina, los objetos de alguna manera debe ser elaborados, en la solución. Esto lleva a los diseños en los que clavijas cuadradas, se han visto obligados a tener los agujeros redondos.

La historia de la informática, está llena de soluciones idealistas a los problemas, empezando casi desde sus inicios: los repetidos intentos de crear una visión global, o un enfoque único para resolver los problemas nos dio a los ensambladores en primer lugar, a continuación, los compiladores y en el camino dio lugar, a una industria artesanal en todo el "Su lenguaje chupa y aquí está el porqué." Los practicantes más pragmáticos, se encogiron de hombros y dijeron: "Cuando todo lo que tienes es un martillo, todo parece un clavo." A medida que las lenguajes, se hicieron más complejaos de alguna manera hemos perdido de vista, el hecho de que una herramienta puede ser utilizada para múltiples propósitos.

Para mí, la iluminación de este éxito sujeto, mientras se escucha hablar  a Anders Hejlsberg, sobre C # 3.0, en la Cumbre de Lenguajes dinámicos, en Redmond, hace unos años. Señaló que C #, es la incorporación de algunas ideas de otros idiomas, y dijo algo en el sentido de "los lenguajes, están perdiendo sus clasificaciones. Ya no podemos decir que un lenguaje, es un lenguaje orientado a objetos, o simplemente un lenguaje dinámico, debido a que muchos de ellos piden prestado, a un montón de ideas diferentes. "

Su comentario se hizo eco de Coplien, las palabras de una década antes: "C + + va más allá [más allá de los paradigmas, que lo precedieron, como la modularidad, tipos abstractos de datos, procedimientos y estructuras de datos] para apoyar de procedimiento, modular, basado en objetos, orientada a objetos y programación genérica en pie de igualdad."

El leguanje C #, va más allá, incorporando conceptos funcionales en la versión 3.0, y los conceptos dinámicos en la versión 4.0. Visual Basic, más dinámico, gracias, desde hace mucho tiempo (a pesar de que fue despreciado por el común), y el objetivo de Microsoft de "la paridad lingüística", entre él y C #, compatible con las mismas características. Sin estos paradigmas de lenguajes adicionales que acechan, bajo la superficie, soluciones como LINQ, son más difíciles, y obligar al desarrollador, a depender de otros mecanismos (por ejemplo, de generación de código, que es en sí misma un aspecto interesante de meta programación, más sobre esto más adelante), para capturar lo común del núcleo de un sistema de trabajo de manera que "se heredan de una clase base" y no se pudo.

Este es el núcleo de lo que vamos a explorar: los fanáticos orientados a objetos del mundo, han insistido durante años, que la herencia representa la mejor aproximación a la reutilización de código. (Esta es la razón  de las clases no están marcados "cerrado" [C #] o "NotInheritable" [Visual Basic], de forma predeterminada.) Y, sin embargo, que es en realidad, no reemplazar los métodos de la clase base, cuando se hereda de la clase Form en WinForms o ASP. NET, sino que proporciona a los delegados, para la invocación. ¿Por qué no reemplazar? ¿Por qué tomar el golpe (por pequeño que sea), de la invocación de delegado? ¿Por qué un código subyacente, pasa de un modelo de herencia basado en un modelo parcial, de clases basada en? ¿Por qué los métodos de extensión en todo?

Las respuestas, a cada una de estas preguntas puede ser (¡y han sido!) se explica en la terminología orientada a objetos, pero la razón de fondo sigue siendo el mismo: no todo puede ser representado en el diseño de objetos clásicos, de las construcciones. Tratando de encontrar las partes comunes de código y reuniéndolos, en una programación única de construcción (que la programación orientada a objetos que tienen es una clase, y estructurales de primera clase, se consideren es una estructura de datos, y la programación funcional mantendría, es una función, y así sucesivamente), es el objetivo del diseño de software, y las formas podemos variar las partes del código, que la variación de la necesidad, más se puede escribir que el tiempo de los sistemas de los duros inviernos, de los clientes que llaman con "Sólo una cosa pequeñita se me olvidó comentarte... "

Como ejercicio, piense en esto: NET Framework 2.0, introdujo los genéricos (tipos de parámetros). ¿Por qué? Desde una perspectiva de diseño, ¿para qué sirven? (Y para que conste, las respuestas de "Nos permite tener colecciones con seguridad de tipos", no viene al caso de Windows Communication Foundation, que utiliza ampliamente los genéricos, con claridad en formas, que no son sólo acerca de las colecciones con seguridad de tipos.)

Vamos a entrar en eso en la siguiente pieza.

Not Dead (o Hecho) Sin embargo,!

Es evidente que hay mucho, mucho más aún que decir sobre este tema, cada uno de los paradigmas actuales en el. NET Framework, merece una exploración y explicación, completa con código, si esta primera parte, no se va a hacer ningún sentido para el desarrollador, de trabajo. Las partes posteriores se vienen, por lo que aguanta. Por el momento hemos terminado, espero (y creo) que tendrá una gran cantidad de herramientas de diseño, para la construcción de lo bueno (y con esto quiero decir bien resumido, mantenible, extensible y útil) de software.

Pero por ahora, se centran en ver los diseños actuales, que está trabajando, y ver si puede identificar las partes del diseño, que utilizan algunos de los conceptos de alto nivel, de cada uno de los diferentes paradigmas, obviamente, las partes objeto se ser relativamente fáciles, de detectar, por lo que se concentran en algunos de los otros. ¿Qué partes de su código base (o el. NET Framework), son de naturaleza procesal, o metaprogrammatic?

Por cierto, si hay un tema en particular que te gustaría, ver explorado, no dude en escribirme una nota, y  lo veremos, tratando de programar una vez que hayamos terminado con esta serie en particular. De una manera muy real, es su columna, después de todo.

¡Feliz de codificación!

---

Ted Neward,  es un principal con Neward & Associates, una firma independiente especializada en la empresa. NET Framework, y la plataforma de sistemas de Java. Ha escrito más de 100 artículos, es un # MVP, INETA altavoz C y el autor o coautor de una docena de libros, incluyendo la próxima "F # 2.0 Profesional" (Wrox).Realiza trabajos de consultoría y mentores con regularidad. Llegar a él en ted@tedneward.com y leer su blog en blogs.tedneward.com.