Discusión: "¿cuál es tu grado de madurez en POO?"

Todo surgió respondiendo una consulta en un foro y me pareció interesante discutirlo aquí. Les comparto los "niveles" o "etapas" que considero que todo desarrollador pasa cuando decide dejar atrás la programación estructurada.

Generalmente todos empiezan por el primero y luego pocos llegan hasta el último (la mayoría solo logra llegar al 2 y se estancan en el 3):
  1. "Programación Estructurada": el inicio, desde donde parten, la "nada" ;-)
  2. "Programación Estructurada con uso de Objetos": usan objetos "sueltos / aislados", no los saben relacionar entre ellos, se reusan a leer material con "conceptos", creen que es mejor aprender a través del "prueba y error".
  3. "Programación Orientada a Objetos Sin Conceptos Claros": "creen que lo hacen bien" pero luego heredan clases mecánicamente pensando que es el mejor mecanismo para reusar código.
  4. "Desarrollo 100% OO": personas que invirtieron sabiamente su tiempo para aprender primero los conceptos para luego poder aplicarlos de forma correcta

Puedes seguir desarrollando estructurado y apoyarte en algunos objetos, pero lo ideal es que te vayas adecuando a la forma de trabajo con objetos y estructures todo el sistema de esta forma (y eso empieza por "pensar en objetos", no en código).

Nuevamente, "crear clases y jugar con objetos" es algo que todos podemos hacer, pero desarrollar "orientado a objetos" es un tema más de tener los conceptos claros que de saber la sintaxis de cómo se codifica.

Recomiendo que antes de preguntar qué es o qué no es POO, revisar el apartado de Wikipedia sobre POO y paradigmas de programación y las diferencias entre ellos.

¿Tú, en qué nivel de madurez estás? ¿crees que hay otros niveles o etapas más? ;-)

6 comentarios:

Isra dijo...

¿En que nivel están los que, conociendo POO empiezan a desarrollar su propio framework? :-P

Creo que en la escala faltan los patrones de desarrollo... y la Programación Orientada a Aspectos, aunque PHP todavía está muy verde en ese tema.

Ali dijo...

Aun no entiendo la diferencia que tu le das entre la 3 y la 4; a que te refieres con que "creen"??
Algo como crear una clase simplemente para rehusar métodos?.
Bueno yo me considero en la 4º. Aprendí poo con java, y pues eso ayuda bastante por que no te deja practicar programación estructurada.

GeL/T0 dijo...

Cada vez que veo proyectos en el estado 2 en PHP me dan ganas de dejarlos, y salir corriendo... El claro ejemplo está en Wordpress :-p

Situarme en algún punto... Entre el 3 y el 4... Me molesto y muy mucho en programar orientado a objetos (no recuerdo la última vez que hice una simple función), pero de ahí a hacerlo perfecto.... Pero bueno, estamos en ello! Que para aprender siempre hay tiempo ;-)

Smalltalk dijo...

Simplemente la frase de Alan Kay: "I invented the term Object-Oriented, and I can tell you I did NOT have C++ in mind". El termino "POO" esta muy distorcinado, por ejemplo segun Alan Kay C++ NO es OOP, porque no tiene garbage collector. POO se refiere a "ambientes puros en Objetos" como Smalltalk y Self o se refiere a hibridos como C++, Java, C#, etc.

PaK0s dijo...

pues.. yo digo que por hay de un 3.7, digo ese "creen" ps deja a la duda, pero igual tu "crees" que lo que haces es lo mejor y estas en 4, creo el "creer" es muy subjetivo, tabien yo traigo mucha filosofia de Java y trato de implementar la OOP que se maneja en java en PHP

Fco Diaz
www.devitics.com.mx

Manuel dijo...

Heme aquí un artículo interesante, a tenor de lo expuesto:

http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html

Un extracto:

--------------------------
... here are some rules of thumb that you can apply to see if you're really looking at an object-oriented system:

1. All data is private. Period. (This rule applies to all implementation details, not just the data.)
2. get and set functions are evil. (They're just elaborate ways to make the data public.)
3. Never ask an object for the information you need to do something; rather, ask the object that has the information to do the work for you.
4. It must be possible to make any change to the way an object is implemented, no matter how significant that change may be, by modifying the single class that defines that object.
5. All objects must provide their own UI.


If the system doesn't follow these rules, it isn't object-oriented ...
--------------------------

Entradas populares