código escrito · artículos digitales de informática
 
Programación orientada a cero
28.11.2003 :: Jaime Irurzun

Uno de los primeros posts que escribí en este blog fue sobre mi preferencia para programar creando funciones generales útiles para cualquier programa. En los comentarios de ese post se formó un interesante debate sobre si es más eficiente escribir este tipo de funciones a pesar de que puedan llegar a ser muy largas en algunos casos o si por el contrario es mejor ceñirse a cada caso particular. En el último comentario enviado por Al González, habla sobre una técnica que comparte tanto ideas de mi postura como de otras más contrarias. La ha bautizado como 'Programación Orientada a Cero (PCO)':

[...] Es una técnica de programación que empleo desde hace más de 10 años, pero que apenas hace tres o cuatro bauticé con ese nombre. Es un superconjunto de la técnica de Generalización aquí planteada. El ingrediente extra es: la atomización de código (o programación atómica).

La atomización consiste en dividir en el mayor número de funciones posibles el código de la biblioteca. Es así como se puede conseguir un producto a la medida particular del cliente, hecho con una biblioteca de propósito general. La arena ocupa mejor el espacio de un cubo, que las rocas de mayor tamaño.

Uno de los principios de la POC, es precisamente lo que comenta Jaime al principio: la mayor parte del código desarrollado para una aplicación, debe quedar en elementos reutilizables dentro de una biblioteca de propósito general. Los tres principios fundamentales de la POC son:
  • Centralización
  • Atomización
  • Gestión de bibliotecas
Bajo esta técnica desarrollé la biblioteca Interfaz GH para Delphi. Contiene más de mil funciones de propósito general, que hoy en día me ahorran cientos de horas de programación en cada proyecto de software.

Interfaz GH va creciendo con cada aplicación que desarrollo y la comparto con la comunidad global de desarrolladores en el foro Programadores Delphi de México (http://groups.msn.com/ce77cj5fut58ai6vahamsb3nb1)

Ahí mismo se encuentra un artículo más amplio sobre lo que es la Programación Orientada a Cero:

http://groups.msn.com/ce77cj5fut58ai6vahamsb3nb1/poc.msnw

Por último, debo agregar que no sólo debe aplicarse la POC siempre que sea posible (algunos compiladores no soportan bien la atomización), sino que también debe emplearse una Gramática de Desarrollo de Software, es decir, una serie de normas que nos dicten cómo debemos nombrar a una función, tipo de dato, variable, etc., o si debemos poner espacio o no después de coma, etc., ya que estos pequeños pero importantes detalles nos ayudan a hacer más legible nuestro código fuente, y por ende, su depuración es más efectiva. [...]
comentarios (8) |


Comentarios del artículo
1 · edmz · 03.12.2003

Estoy de acuerdo en lo práctico y util de dichas funciones pero antes que la generalización creo que esta el tiempo de desarrollo. A veces se invierte tanto en tiempo en generalizar una función que el tiempo ahorrado en total por dicha función es negativo: se termina generalizando para algo que no se sabe con certeza que se aprovechara en el futuro y se invierten horas generalizando algo que si no estuviera en forma generalizada llevaría una fracción del tiempo. Aqui la pregunta sería qué tanto generalizar. Creo yo que solo aquello que tenga utilidad en el futuro muy visible y cercano.

2 · Fernando Herrero · 04.12.2003

El tema de la generalización parece un tema de esos recurrentes...
La realidad me ha enseñado que hay tantas maneras de programar como programadores hay en el mundo, por lo que es muy dificil que una "metodologia" se adecue a todos ;-)
Por otro lado hay problemas simples que la primera vez que te toca resolverlos ves claramente que te olvidarás para siempre de ellos si los metes dentro de una función en una libreria... otros tendrán que esperar a que sea la enesima vez que te tropieces con ellos para despertar al perezoso que todos llevamos dentro...

Yo no dedico tiempo exclusivamente a crearme librerias, mi forma de programar ya facilita mucho la tarea ya que todas las funciones que creo las pongo al principio del script, asi si vuelvo a necesitar una función que cree para un proyecto puedo encontrarla rápidamente y es entonces cuando la incorporo a una de las librerias que tengo y el tiempo que me he ahorrado lo invierto en retocar la función ;-)

Saludos

3 · edmz · 04.12.2003

De acuerdo totalmente contigo en lo de que formas de programar hay tantas como programadores. La mejor forma es aquella que funcione para ti pero siempre abierto a nuevas formas, posibilidades.

4 · Walito · 07.12.2003

La generalización debe dos contras, excesiva utilización de la pila de funciones y dificil administración de las funciones a medida que va creciendo la cantidad de funciones disponibles.
Con mil funciones disponibles, y despues de pasado un buen tiempo de hechas, como haces para acordarte o buscar una función que hacía lo que estás necesitando ?.

Otro de los problemas que trae esto (lo estoy leyendo en la Dr.Dobb's Journal) es la reutilización de un código que se asume correcto, y que funciona correctamente en otros lugares, pero que en el rango de datos posibles (incluyendos los posibles por errores de usuario o del sistema que son los que generalmente no se toman en cuenta) genere problemas de seguridad o mal funcionamiento al sistema.

Por supuesto que no digo que se reescriba todo el código en cada nueva aplicación, pero si que hay que tener un balanceo correcto.

5 · Fernando · 07.12.2003

Walito, no sé por qué pero me recuerdas a Matrix Reloaded ;-)
El tema de las librerias es tan viejo que se viene utilizando desde que se invento la escritura: asi de vagos somos ;-D

Si como dices el problema de las librerias es controlar las funciones que existen en ellas tambien es cierto que segun no necesitamos ciertas funciones que en cierto momento fueron utilizadas a dirario, nos vamos olvidando de ellas y llegará el día en el que comecemos a recrearlas (quizás porque ni nos acordemos de que las tenemos o por el mero echo de volver a "disfrutar" creando algo verdaderamente útil para nosotros ;-).

El otro problema que comentas sólo es problema si asumimos dos cosas:
- Mala programación
- Mal uso de las funciones

La segunda es síntoma de la primera, y es evidente que un mal uso de las funciones (en el caso de que el código de la función sea totalmente correcto) es posible y existe incluso en las propias funciones del propio lenguaje de programación que utilicemos: por eso existen bugs y agujeros.

La mala programación sólo tiene dos soluciones:
- Más horas de programación.
- Dejar de programar.

Que cada cual elija su opción ;-)
Saludos

6 · anonimo · 27.07.2004

falta más información hacerca del tema tipo de entidades la explicacion especifa de que es una relacion fuerte, devil y derivada

7 · Ricky Alvarado c. · 26.01.2005

hola proporcionarme mas informacion que sea datada a mi correo gracias la informacion de este codigo es muy importante gracias

8 · Ricky Alvarado c. · 26.01.2005

hola proporcionarme mas informacion que sea datada a mi correo gracias la informacion de este codigo es muy importante gracias














































Creative Commons - Jaime Irurzun y Aitor Martin