TraduccionMartinFowler's blog

LecturasDSL

Thu, 26 Jul 2007 09:48:24 +0000

Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

( Ver mi nota sobre LenguajeDeDominioEspecífico para una rápida introducción a este tema y a la terminología.)
Actualizado:David Laribee ha escrito un post contrastando lo que él llama interfaces fluidos ordenados o interfaces fluidos desordenados. La distinción es que los interfaces fluidos ordenados fuerzan a un flujo particular sobre cómo se compone una sentencia DSL. Él proporciona un ejemplo donde usa múltiples interfaces sobre un único ExpressionBuilder- la misma técnica que se usa por JMock.

Anders Noras ha escrito dos artículos interesantes sobre la escritura de DSLs internos en C#. El primer artículo da un ejemplo del DSL y una discusión contra la cínica lista de comprobación de Chromatic. El segundo artículo entra en detalles sobre su implementación.
Piers Cawley hacen incapié en que una característica clave de DSLs es su estrecha focalización en un dominio

ErroresDeConceptoDeLaProgramaciónPorParejas

Tue, 24 Jul 2007 13:19:14 +0000

Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

Se tiene que programar por parejas si se sigue un proceso ágil.
Esto es completamente falso. 'Ágil' es un término muy amplio definido sólo en términos de valores y principios, el más notablemente en el Manifiesto para el Desarrollo de Software Ágil. El manifiesto no menciona el programar por parejas y la mayoría de los métodos ágiles no lo incluyen en su aproximación.
Ya que programar por parejas es una práctica de XP, ha tenido mucha influencia en la comunidad ágil. Por consiguiente a menudo es mencionado como una práctica ágil – tomando como práctica algo que es comúnmente usado por la gente en proyectos ágiles. Pero esto es una observación, no una prescripción..

AbismoParaLaMejora

Mon, 23 Jul 2007 08:20:47 +0000

Escrito por Martin Fowler
Traducido por Rafael Vacas

Si te importa lo que haces, te interesas en hacerlo cada vez mejor. Esto implica reflejar como haces las cosas y probar nuevas técnicas para ver si te hacen mejorar. Aunque otros recomienden nuevas técnicas, la única forma de saber si funcionan para ti es probándolas tú mismo y comprobar si mejoran tu rendimiento.

El problema es que la mejora, particularmente con nuevas técnicas no es lineal. A menudo hay una brecha que se abre cando intentas una nueva estrategia. La mejor ilustración que recuerdo de esto es del excelente libro de Gerald Weinberg Convertirse en un Líder Técnico. Viene de su hábito de jugar al pinball.

A medida que iba mejorando lentamente en mi nivel, empecé a sospechar que se me estaba pasando algo. Aunque mi puntuación subía rápidamente cuando tenía tres bolas en juego, de repente, al intentar mantener las tres bolas en juego, perdía las tres de golpe. Sólo pasaba una de cada cuatro veces, pero eso significaba que había perdido uno de tres preciosos turnos.

Me preguntaba que pasaría si dejaba de intentar mantener las 3 bolas en juego y me concentraba en su lugar en asegurar que una de las tres bolas se mantuviera en el campo de juego. Cuando probé esta nueva estrategia, mi puntuación cayó, inmediatamente, en el abismo. De hecho, estaba jugando contra un chiquillo al mismo tiempo, y empezó ganándome. Incapaz de afrontar la derrota, volví a mi antigua estrategia y lo puse en su lugar.

Más tarde, sin embargo, sin público observando, probé la nueva estrategia de nuevo. Y de nuevo mi puntuación bajó, pero me di cuenta de que no estaba perdiendo turno con tanta frecuencia, quizá sólo una de cada cinco veces que jugaba con tres bolas al mismo tiempo. Perseverando, con la práctica, mejoré mi habilidad para ignorar las otras dos bolas y mantener al menos una en el campo. No puntuaba mucho cuando las tres bolas estaban en juego, pero mi puntuación total aumentó. También conseguí jugar más tiempo en mi turno, lo cual es uno de los principales objetivos del juego.

HerenciaDiseñada

Mon, 23 Jul 2007 08:07:10 +0000

Escrito por Martin Fowler
Traducido por Rafael Vacas

Uno de los más largos debates en los círculos orientados a objetos es el debate entre HerenciaAbierta y HerenciaDiseñada. Josh Block ha sido probablemente quien mejor ha resumido el principio de la herencia diseñada: “Diseña y documenta para herencia o si no prohíbela”. Con este planteamiento te preocupas de decidir qué métodos pueden ser heredados y proteges los otros para evitar que sean sobrescritos.

El argumento más común para la herencia diseñada es que dado que la herencia supone una relación muy estrecha (y rompe la encapsulación) es fácil que las subclases efectivamente rompan las superclases por ejemplo, omitiendo comportamientos necesarios cuando sus métodos son invocados.

Muchos programadores, particularmente aquellos con una ActitudPermisiva, no están muy convencidos por este estilo de argumento. Otro argumento que encuentro más apetecible es el de Elliote Rusty Harold al discutir los principios de diseño de XOM. La cuestión aquí es que “las API son escritas por expertos para no expertos”. El creador de librerías debería estar debidamente versado en la tecnología con la que trabaja la librería. Deberían trabajar para simplificar esta tecnología a los usuarios de la librería. La encapsulación consiste en esconder secretos, por tanto una buena librería debería esconder toda clase de complicaciones y puntos peligrosos a los usuarios de la librería, ya usen la librería mediante invocaciones o herencia. Por tanto, con XOM puedo sobrescribir de forma segura las clases de la librería para hacer lo que quiera ya que la librería garantiza que aún así producirá XML bien formado, sin que tenga que preocupar a mi fea cabecita con todas las cosas que de otra forma podrían ir mal.

Diseño planificado y Evolutivo

Thu, 12 Jul 2007 15:23:44 +0000

Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

Para este artículo voy a describir dos estilos de cómo se hace el diseño en el desarrollo de software. Quizás el más común es el diseño evolutivo. Esencialmente, el diseño evolutivo quiere decir que el diseño del sistema crece mientras se implemente el sistema. El diseño es parte de los procesos de programación y según el programa se desarrolla el diseño cambia.

En su uso habitual, el diseño evolutivo es un desastre. El diseño termina siendo la agregación de un manojo de decisiones tácticas tomadas en el momento, cada una de las cuales hace el código más difícil de cambiar. Se podría argumentar de muchas formas que esto no es diseño, de hecho esto por lo general conduce a un diseño pobre. Como Kent dijo, el diseño está ahí para permitir cambiar el software fácilmente a largo plazo. Como el diseño se deteriora, entonces se necesita la capacidad de hacer cambios con eficacia. Se tiene el estado de entropía de software, con el tiempo el diseño se pone de mal en peor.

No sólo hace esto el software más difícil de cambiar, esto también hace los errores más fácil de reproducirse y a la vez más difícil encontrar y seguramente para resolver. Esto es la pesadilla “codificar y arreglar”, donde los errores se hacen exponencialmente más caros de arreglar según el proyecto avanza.

HypótesisDeResistenciaAlDiseño

Wed, 11 Jul 2007 12:15:06 +0000

Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

¿Merece la pena el esfuerzo para diseñar el software bien?

De vez en cuando tengo conversaciones indirectas sobre si el diseño de buen software es una actividad que vale la pena. Digo que estas conversaciones son indirectas porque no creo que me haya encontrado a nadie diciendo que el diseño de software no tiene importancia. Por lo general es expresado de la forma " realmente tenemos que ir rápido para cumplir nuestro objetivo el próximo año y entonces reducimos ".

Existe la noción de que el diseño es algo que se puede comerciar para conseguir una mayor velocidad. De hecho he tenido la impresión un par de veces de que el esfuerzo de diseño es aceptado para mantener a los programadores felices aun cuando esto reduzca la velocidad.

AdoptandoPropiedadDelCodigo

Thu, 08 Jun 2006 08:02:30 +0000

Escrito por Martin Fowler
Traducido por Jorge Ferrer
Revisado por Carmen Vidal

En la reciente entrada de mi bliki Propiedad de código (CodeOwnership), describí mi modo de ver diversos asuntos relacionados con quien es responsable del código. Muchos de mis amigos son practicantes de Extreme Programming (XP) y tienden a favorecer la propiedad colectiva del código. Sin embargo este tipo de prácticas no son absolutas y siempre deben ser tenidas en cuenta por las consideraciones del momento y lugar. Un de mis colegas me envió hoy una nota con la siguiente historia que he pensado que era un buen indicador de cuándo debes cambiar tus prácticas, incluso aunque seas un fan de XP. (Como este colega habla de su propio equipo, prefiere permanecer anónimo):

Yo cambié nuestro equipo de un modelo 'colectivo' a un modelo de propiedad 'débil' del código para contrarrestar la programación indisciplinada de un par de desarrolladores. Combinada con un poco de realimentación imparcial, el resultado fue una mejora de la velocidad dado que los desarrolladores que ahora “poseen” nuestras partes clave del código no están constantemente rehaciendo código de baja calidad, mientras que los que solían hacerlo se dedican a asuntos como búsqueda de defectos o cambios de código con poco riesgo – lo que libera tiempo del resto.

PropiedadDelCódigo

Thu, 08 Jun 2006 08:10:04 +0000

Escrito por Martin Fowler
Traducido por Jorge Ferrer
Revisado por Carmen Vidal

Existen varios enfoques para afrontar la propiedad del código que se escribe. Yo las organizo en tres grandes categorías:

• Propiedad fuerte del código:divide el código fuente en módulos (clases, funciones, ficheros) y asigna cada módulo a un desarrollador. Estos sólo tienen permiso para realizar cambios en sus módulos. Si necesitan hacer un cambio en el módulo de otro desarrollador deben hablar con él para que lo realice. Este proceso puede acelerarse escribiendo un parche para el otro módulo y enviándoselo al desarrollador propietario.

• Propiedad débil del código: es similar al anterior en el sentido de que los módulos también son asignados a desarrolladores concretos, pero diferente en que también se permite que otros desarrolladores realicen cambios. Los propietarios de cada módulo deben tomar responsabilidad de los mismos revisando los cambios que otros realizan en ellos. Si un desarrollador quiere realizar un cambio sustancial en un módulo que no le ha sido asignado se considera conveniente hablar con el propietario antes de llevarlo a cabo.

• Propiedad colectiva de código:abandona por completo la noción de propiedad individual de los módulos. El código fuente es propiedad del equipo entero y todos pueden realizar cambios en cualquier parte. Puede considerarse este enfoque igual a no tener ningún tipo de propiedad de código, pero sus defensores prefieren poner el énfasis en la noción de propiedad por parte de un equipo en contraposición a propiedad por parte de un individuo. (El término propiedad colectiva del código, Collective Code Ownership en inglés, viene de Extreme Programming, aunque en su segunda edición se ha renombrado como Código compartido o Shared Code en inglés)

EvaluandoRuby

Thu, 25 May 2006 14:02:38 +0000

Escrito por Martin Fowler
Traducido por Rafael Vacas
Revisado por Jorge Ferrer

Si estás leyendo esto, asumo que estás enterado de que ha habido una gran agitación entorno al lenguaje de programación Ruby y en particular de Rails, el framework para el desarrollo de aplicaciones Web. Algunos lo ven como el futuro de la programación, otros como una diversión peligrosa.

Empecé con Ruby hace algunos años. Los
Programadores Pragmáticos lograron captar mi atención y pronto se convirtió en mi lenguaje de script preferido. Con el tiempo he llegado a usarlo en gran parte de la producción de este sitio Web, en particular de este bliki. Me encanta este lenguaje.

Hay que distinguir entre mi gusto personal y si es algo que deban utilizar nuestros clientes. Podemos determinar su conveniencia en función de las características de los proyectos de estos clientes – y esto nos lleva a muchos argumentos sobre los pros y contras de la definición dinámica de tipos, convención sobre configuración, procesos versus threads (hilos) y otros. Tales discusiones son útiles, pero sigo siendo cauteloso con ellas. Hay demasiados asuntos que son difíciles de juzgar de esta forma y al final acabamos desperdiciando el tiempo en proyectos que son ralentizados por usar una tecnología que sonaba bien durante un partido de golf. Yo prefiero realizar estos juicios basándome en la experiencia – encontrar gente con experiencia exitosa en proyectos y que hayan usado Ruby.

ErradicadorDeMétodosGet

Wed, 01 Mar 2006 16:18:09 +0000

Escrito por Martin Fowler
Traducido por Jorge Ferrer

Puedes reconocerlos por el tick en el lado izquierdo de la boca cada vez que ven un método get (getter). Se produce un movimiento rápido de su hacha de guerra y se oye un grito de satisfacción cuando un getter es eliminado sin piedad de una clase que inmediatamente se desvanece en un éxtasis de agradecimiento a los pies de erradicador de métodos get.

Está bien, quizá el volver a la cerveza inglesa me está afectando demasiado, pero el “pellizco cariñoso” de Chris despertó una cruzada personal mía. A menudo me he encontrado con gente que recomienda evitar métodos get en las clases, considerándolos una violación de la encapsulación. El artículo de Allen Holub es uno de los más conocidos.

Implementacion De Interfaces Implícitas

Wed, 15 Mar 2006 15:30:39 +0000

Escrito por Martin Fowler
Traducido por Jorge Ferrer

(17 de Enero de 2006 – Actualización general a la luz de varios comentarios)

Tanto Java como C# tienen el mismo model de interfaces puras. Se declara una interfaz escribiendo interface Mailable, y después puede implementarse escribiendo class Customer implements Mailable (en Java). Una clase puede implementar varias interfaces.

Una de las cosas que este modelo ignora es que pueden tenerse interfaces implícitas en una clase. La interfaz implícita pública de la clase Customer la componen todos los métodos públicos de Customer. (Esta interfaz implícita está presente en todos los lenguajes orientados a objetos que he visto.) Una cosa que ni Java ni C# te permiten hacer es implementar una interfaz implícita – es decir no te permite escribir class ValuedCustomer implements Customer.

¿Qué significaría implementar una interfaz implícita? La esencia sería que le diría al sistema de tipado que la clase ValuedCustomer implementa todos los métodos declarados en la interfaz pública de Customer pero que no usa sus implementaciones, es decir los cuerpos de los métodos públicos y los datos y métodos no públicos. Dicho de otra manera se trata de herencia de interfaz pero no de implementación.

Sería equivalente a convertir Customer en una interfaz que contiene todos los métodos públicos de Customer y crear una clase CustomerImpl que implementa dicha interfaz.

LenguajeDeDominioEspecífico

Sun, 19 Feb 2006 21:53:21 +0000

Escrito por Martin Fowler
Traducido por Miguel Figueroa-Calix
Revisado por Carmen Vidal

La idea básica de un lenguaje de dominio específico (DSL por sus siglas en ingles) es que en vez de ser una lengua de proposito general que se dirige a cualquier clase de problema de programación, es un lenguaje de programación que ataca a un problema particular. Los lenguajes de dominio específico se han discutido y utilizado casi desde los inicios de la computación.

Una comunidad que utiliza mucho los DSLs es la comunidad de Unix donde se les refiere a menudo como pequeños idiomas o mini idiomas. (Eric Raymond proporciona una buena discusión de esta tradición). El enfoque más común al estilo unix es definir una sintaxis de la lengua y entonces o bien usar la generación de código para un lenguaje de propósito general, o escribir un intérprete para el DSL. Unix tiene muchas herramientas que hacen esto más fácil. Yo utilizo el término DSL Externo para referirme a esta clase de DSL. Los archivos de configuración de XML son otra forma común del DSL externo.

Las comunidades de Lisp y Smalltalk también tienen una fuerte tradición de DSLs, pero tienden a hacerlo de otra forma. En vez de definir un nuevo lenguaje, ellos moldean el lenguaje de proposito general dentro del DSL. (Paul Graham proporciona una buena descripción en Programación de abajo para arriba .) Este DSL Interno (también llamado el DSL encajado) utiliza la construcción del lenguaje de programación en sí mismo para definir al DSL. Esta es una manera común de trabajar en cualquier lenguaje, yo siempre he pensado en definir funciones de tal manera que proporcione una forma de DSL para mi problema. Pero a menudo lispers y smalltalkers toman esto a niveles mas altos.

InicializaciónConSetters

Thu, 09 Feb 2006 09:05:54 +0000

Escrito por Martin Fowler
Traducido por Jorge Ferrer
Revisado por Carmen Vidal

Este es uno de los dos enfoques para inicializar objetos, el otro es InicializaciónEnElConstructor.

En la inicialización con setters primero se construye un objeto y después se usan métodos setter para inicializar diferentes propiedades según se necesitan. Así que la creación de un objeto Person que represente una persona con nombre, apellido y una colección de sus bares favoritos sería algo así:

#ruby
mf = Person.new
mf.firstname = 'Martin'
mf.lastname = 'Fowler'
mf.add_bar "Turner's Oyster Bar"
mf.add_bar "Square and Compass"

Este enfoque proporciona la máxima flexibilidad para asociar objetos.
Permite proporcionar los colaboradores realmente necesarios para un uso específico, también te libera de tener que proporcionar todos los valores de una vez con lo que se evita el problema de listas de parámetros demasiado largas en los constructores y una larga colección de constructores entre los cuales elegir.

Artículo Original

InicializaciónEnElConstructor

Thu, 09 Feb 2006 09:53:29 +0000

Escrito por Martin Fowler
Traducido por Jorge Ferrer
Revisado por Carmen Vidal

Este es uno de los dos enfoques para inicializar un nuevo ejemplar de una clase, el otro es InicializaciónConSetters.

La inicialización en el constructor es un enfoque en el que se intenta garantizar que siempre se crea un ejemplar de una clase en un estado válido proporcionándole todos los colaboradores que el objeto necesita en el método usado para crear el objeto. De esta manera para crear un objeto Person que represente a una persona con nombre, apellidos y una colección de sus bares favoritos podríamos ver algo así:

# ruby
mf = Person.new('martin', 'fowler',
['Turners Oyster Bar', 'Square and Compass'])

De esta manera siempre te aseguras de que tienes un objeto en un estado razonablemente bien formado que está listo para ser usado. Es un enfoque compacto, que permite usarlo o invocar alguno de sus métodos en una sola línea, lo que significa que no necesitas una variable adicional en el código.

Declarar todos los colaboradores necesarios en el constructor deja claro qué colaboradores son necesarios, con lo que es más fácil averiguar cómo preparar la clase para su correcto funcionamiento. Será necesario tener un método constructor por cada combinación válida de colaboradores obligatorios. También suele resultar cómodo proporcionar constructores que incluyen también colaboradores opcionales pero habitualmente usados.

OlorEnElCódigo

Thu, 09 Feb 2006 09:08:17 +0000

Escrito por Martin Fowler

Traducido por Jorge Ferrer

Revisado por Carmen Vidal

Es un síntoma superficial que normalmente lleva asociada un problema más profundo en el sistema. El término (inglés original) fue inventado por Kent Beck mientras me ayudaba a escribir el libro Refactoring.

La definición rápida del párrafo anterior deja un par de puntos difíciles de percibir. En primer lugar un mal olor es por definición algo que es rápido de descubrir – es sniffable (susceptible de ser olido) como he comentado recientemente. Un método largo es un buen ejemplo de esto – simplemente mirando al código mi nariz se estremece si veo más de doce líneas de Java seguidas.

En segundo lugar los olores no siempre indican un problema. Algunos métodos largos son razonables. Debes mirar en profundidad para ver si hay un problema subyacente en ese caso – los olores no son inherentemente malos por si solos – son a menudo un indicador de un problema más que un problema en su mismos.

Los mejores olores son fáciles de encontrar y que la mayor parte de las veces conducen a problemas interesantes. La clases de datos (clases que son todo datos y no tienen ningún comportamiento) son un buen ejemplo de esto. Las miras y te preguntas qué comportamiento debería tener esa clase. Entonces comienzas a refactorizar para mover comportamiento dentro de ella. A menudo preguntas sencillas y refactorizaciones inicalies pueden ser el paso vital para convertir objetos anémicos en algo que realmente tiene una clase.