Presentación: "Construyendo Entornos de Desarrollo Escalables"

Buscando presentaciones sobre "gestión ágil", metodologías y en concreto sobre Scrum, me encontré con esta de casualidad. Muy interesante, se las comparto:

| View | Upload your own

"Surforce CMS": nueva lista de tareas pendientes

Estoy en estos momentos ingresando en una planilla de Google Docs la lista de tareas pendientes a realizar sobre el CMS que estamos desarrollando de forma colaborativa, con el simple objetivo de aprender entre nosotros a usar Zend Framework.

Si quieres participar -necesitamos revitalizar el equipo de trabajo- esta es tú oportunidad; deberás simplemente y por cuenta propia (hay mucha información en este blog de cómo hacerlo):

1. Reconstruir localmente el CMS
2. Elegir alguna de las tareas pendientes
3. Implementarla
   
4. Enviarme por mail el código nuevo (un "diff" mostrando lo que se hizo)

Si es correcto y funcional, lo que enviaste será agregado al repositorio y tú al grupo oficial de desarrollo para seguir aprendiendo en equipo.

Demuestra que puedes lograrlo y estás dentro. ¡Suerte!

Herencia de clases y el "Principio de Liskov" (actualizado 15/10/2007)

En realidad se llama "Principio de sustitución de Liskov" y el nombre completo es Bárbara H. Liskov (sí, hay mujeres en la informática y han hecho grandes aportes ;-)).

A grandes rasgos dice que el famoso "es un" (is_a) que generalmente usan los docentes para enseñarnos "herencia de clases" no es suficiente.

No basta con "ser" hay que "comportarse como tal".

Generalmente hago el mismo chiste cuando trato el tema en un curso: "un docente es una persona, pero no basta, debe comportarse como tal".

Un ejemplo más real: Sistema de liquidación de sueldos

Si tienes un sistema que liquida sueldos, una clase base Empleado (con atributos como "sueldo" que se usa para calcular su pago) y subclases Gerente, Desarrollador, Administrativa y Becario (asumamos que el último no recibe ninguna remuneración).

Usas polimorfismo y en tu clase Administracion tienes un método liquidarSueldo donde recibirás objetos de tipo Empleado. Bien, cuando en un momento recibes de tu lista de empleados un becario... ¿qué debe hacer el sistema? (ya que haces el cálculo en base al valor que viene en el atributo sueldo y este es heredado por todos desde la clase Empleado).

1. ¿Emitir un comprobante impreso pero con valor 0?
2. ¿Agregar un "if" preguntando si es becario, y no hacer nada?
3. etc

Supongamos que el 1) no es aceptable por el gasto de papel y te piden que no se impriman (no tiene sentido), pasamos al punto 2), agregamos un "if".

¿No estamos "codificando a fuego" nuestro sistema para un comportamiento particular?

Estamos rompiendo el polimorfismo, justamente, el patrón estratégico más importante que tiene la POO. Cada vez que tenemos que cambiar nuestro código generamos nuevos costos y nuevos posibles errores.

Por eso cada vez nos cuesta más desarrollar un sistema, hasta que tenemos que tirarlo y desarrollar otro de cero... y empezamos otra vez con los problemas del mal diseño (code smell).

La base teórica

Los principios de diseño te dicen que "desarrolla cerrado al cambio y abierto a la extensión" (Principio Open/Closed, "Abierto / Cerrado").

Por ejemplo, tu código debe ser reutilizable (¿no es la idea esencial de la OO?) y con solo agregar código -sin tocar el existente- lograrás adecuarte a los cambios, a los nuevos requerimientos. No te olvides que nuestro código lo usan muchos otros objetos, si este cambiara, generaría un efecto en cadena, posiblemente, dejando de funcionar lo ya existente y tener que modificar más objetos.

Esta forma de "extensión" es agregar más clases a la herencia y el método liquidarSueldo no se modifica, pero si tu no haces correctas herencias, no puedes hacer lo primero, por lo tanto tu sistema se degradará en cascada.

Esta simple tontería el autor demuestra con muchos ejemplos que hacer "herencia por herencia", "por reutilizar código", no es suficiente y genera grandes problemas en los diseños.

Es una de las razones que me ven de mal humor cuando veo que implementan herencia a los golpes, prueba y error, con el argumento solo de "reutilizar código"

La conclusión final es...

El problema es que la herencia está mal formulada y que el Becario no se comporta como un Empleado, por lo tanto no puede ir en esa estructura jerárquica, de lo contrario nos va a obligar a desarmar nuestro sistema para tratar de ajustarlo a un comportamiento no adecuado (agregando condiciones explícitas para el mismo, hardcode) y este empezará a dejar de ser reusable.

No se puede hacer herencia por herencia, para reusar código. No se puede hacer herencia simplemente por que un "Becario es un Empleado", hay que estar seguro que además de "ser" se comporte como tal.

Nuestro becario, ya que no cobra una remuneración, no pude pasar por el sistema de liquidación de sueldos. La solución no es ajustar el sistema de sueldos para que lo permita.

Anexo otro artículo relacionado: Herencia Múltiple en PHP5

Nota: este post está basado en una discusión presentada en Foros del Web

Parece que pasamos a las ligas mayores: ¡Namespaces en PHP 5.3!

Me comenta mi colega Julio Viana que se enteró a través del blog de Inwe una muy buena noticia: la disponibilidad en la rama 5.3 de desarrollo de los tan necesitados namespaces. Fue toda una sorpresa, ya que se discutía si estaría recién en la próxima versión 6, pero veo que se han dado cuenta que era una vergüenza no contar con tan básica funcionalidad (los que conocemos lenguajes que se usan en arquitecturas como Java o .Net sabemos que sin esto no se puede vivir).

Si quieres saber de qué te hablo, puedes leer los siguientes post:

• PHP5: Diseño en 3 capas y problemas con subdirectorios
• "Petición para soporte de Name Spaces en PHP5"