PHP: objetos versus procedimientos
Entre otras, la programación en PHP (como en casi todos los otros lenguajes de programación de ordenadores) [perdón, necesitaba densidad de keywords jajaja] puede encararse desde objetos o desde procedimientos.
Como dije, hay otros “enfoques“, pero los dos modelos dominantes son esos. Bueno, al menos para mí, está bien, no todo el mundo es como yo, ya lo recordé.
En fin, mi experiencia es que trabajando con procedimientos uno codea el 40% del tiempo, y debuggea el resto. Con objetos, los números son distintos: codeo el 95% del tiempo y debuggeo el 5%.
Es abismal la diferencia, y es muy placentero trabajar con objetos. Además de las ventajas teóricas que plantea, claro. No es un quick development porque algo mal hecho al principio puede arruinar todo (peor que en procedimientos, donde el fenómeno también existe, claro) y eso hace que se tenga que razonar y arquitecturar mucho al inicio, pero el desarrollo se acelera mucho una vez que se tienen la bases, y además, se pasa más tiempo programando -que es lo que nos gusta, lo que me gusta- y menos resolviendo problemas -que es lo que nos termina irritando, a todos.
Objetos, por ahora los amamos. He dicho.
enero 5th, 2007 at 5:37 pm
Te das cuenta, al final el chiste está siempre en pensar la arquitectura. Pensarla BIEN, y después codear. Es un embole atómico, pero para los sistemas grandes (ya sé, ya sé: definición no medible), algo como UML te puede resolver la vida y ayudarte a ver todos los problemas ANTES de cometerlos.
Para los que no son tan grandes, bastan papel, lápiz y los dibujitos que quieras. O notepad :)
enero 5th, 2007 at 5:37 pm
o google docs !!!
enero 5th, 2007 at 6:20 pm
Lamentablemente si uno no está programando para un jefe, está programando para un cliente. Y si no es ninguno de estos dos casos, uno está programando para uno mismo (ejemplo: un website que ofrece un servicio online, como MercadoLibre o… LIVRA!).
El problema con los jefes y con los clientes es que todo el tiempo cambian los requerimientos en cuanto a la funcionalidad de un proyecto. Eso muchas veces hace que nuestra bellísima arquitectura n-tier quede hecha un asco por que el tipo quiere el cambio ahora, y no está dispuesto a esperar las horas necesarias para poder hacer las cosas como se debe. Uno termina desparramando código de la capa de lógica en la capa de presentación, y a veces también hasta código de la capa de datos… Otra cosa muy común es que las necesidades cambiantes del señor que nos paga hagan que terminemos repitiendo código en un montón de lados por no tener el tiempo necesario para encapsular el código que se repite y reutilizarlo donde se necesite.
Cuando uno trabaja para uno mismo, como dije en el primer párrafo, pasan cosas parecidas. Ahora el monigote tirano casi carente de conocimientos sobre sistemas es uno mismo, que tiene que hacer las cosas a las apuradas para evitar ser devorado por la competencia.
Por lo tanto, mi consejo es no apegarse demasiado fuertemente a una arquitectura y siempre que se pueda usar técnicas ágiles. Y por sobre todo: mantenerlo simple. Yo considero que si una arquitectura necesita de un UML para poder entenderla, es demasiado complicada y no sirve.
El XML no sirve. Crear el modelo de datos en una aplicación en el servidor de bases de datos y tener que repetir todo el modelo cuando hacemos las clases “wrapper” en la capa de datos, no sirve. Tener que repetir el modelo de datos en un archivo XML para hacer un mapping entre las clases wrapper y el modelo de datos en el servidor de bases de datos, tampoco sirve (esto es más o menos lo que hace Hibernate en Java).
Es por eso que Ruby on Rails está bueno. La idea es “convention over configuration”. Es mucho más poderoso hacerlo de esta manera.
Sin embargo no puedo hacer un sistema compuesto por una base de datos, una capa de acceso a datos, una capa de lógica que utiliza la capa de acceso a datos, y finalmente un front-end Ruby on Rails y otro front-end desktop hecho en .NET, ya que Ruby on Rails está hecho para trabajar en un entorno casi exclusivamente web.
Está todo muy verde todavía. El día que pueda escribir mi modelo de datos (no me importa si es gráficamente en una utilidad de una base de datos, en un archivo de texto, o como código), crear lógica que manipule los datos de acuerdo a ciertas reglas, y que pueda acceder a esta lógica desde cualquier parte SIN REPETIR nada (es decir, NO archivos de configuración XML, NO hacer wrappers para acceder por Corba o XMLRPC (Python ya es muy bueno evitando hacer wrappers por ejemplo para acceder a web services gracias a su gran capacidad de introspección), NO duplicar estructuras de datos entre el código y el servidor SQL) el mundo va a ser un lugar mejor :-)
Mientras tanto arréglense con lo que hay: lenguajes dinámicos con grandes capacidades de introspección y técnicas de programación ágil.
Saludos.
enero 6th, 2007 at 7:39 pm
entre paréntesis, café dio cátedra.
bienvenido el manifiesto. estamos juntos en esto.