Todavía recuerdo la primera vez que entré en contacto con los conceptos de la programación orientada a objetos. Yo estaba navegando en msdn library (vs6) en una sección denominada libros y tropiezo con un libro llamado «Visual basic 6 business objects». Había sólo unos capítulos incluidos pero los encontré increíbles. Habia aprendido y llevaba escribiendo aplicaciones vb6 por un tiempo para entonces pero encontré el vocabulario extraño: «Objeto de negocio», «Encapsulamiento», «Polimorfismo» y así sucesivamente. Inmediatamente me enganchó. Entre más aprendía, más quería empezar a codificar en este modo nuevo y maravilloso. Pero cuando tuve que escribir el código, me pareció tan difícil empezar! La cosa es que la programación orientada a objetos requiere una nueva mentalidad y este cambio toma tiempo.
El problema
Creo que el problema surge porque casi cada desarrollador es expuesto primeramente a la programación por procedimientos y generalmente tarda mucho tiempo para ser expuesto a la programación orientada a objetos. También la enseñanza de la programación orientada a objetos es a menudo muy pobre. Estos 2 hechos combinados con un montón de tutoriales por ahí para aprender lenguajes orientados a objetos que no consisten mas que en ejercicios de programación por procedimientos impone el estilo por procedimientos mas firmemente en la mente de los programadores.
Así que ¿como se ve el código por procedimientos? Hay tantas maneras y formas que en lugar de un ejemplo compartiré algunos indicadores.
- Los objetos contienen o sólo datos o sólo métodos
- Los objetos muestran datos con el único propósito de ser utilizado por otra parte
- Casi la totalidad de la lógica esta en métodos estáticos
De pensamiento por procedimientos a orientado a objetos
Así, la programación por procedimientos se trata de los procedimientos y los datos que pasas a ellos. Empiezas a pensar cuáles son las variables, cómo se representan (estructuras de datos) y qué hacer con ellas mientras que un estilo objeto orientado a objetos te hace pensar en quién hace qué (responsabilidades) y quien trabaja con quien con el fin de completar una tarea (colaboración). El cómo (implementación) es relegado a una etapa posterior. En lugar de pensar sobre los datos y procedimientos, ahora tienes objetos que empaquetan datos y procedimientos para hacer las cosas.
Ahora viene la parte difícil, la mayoría de las veces debes exponer sólo los métodos, no datos (propiedades). Si estás familiarizado con un lenguaje orientado a objetos (como java o C#) intenta escribir un programa sin el uso de propiedades. No expongas datos solo para que alguien mas los utilice. Pide ayuda no datos (encapsulamiento). Esto llevará naturalmente a objetos que tienen datos y los métodos para manipular esos datos. Esto es bueno. Así que en lugar de escribir mailer.send(mail) ahora vas a escribir mail.sendThrough(mailer). Y mailer puede tener algo que parece mailer.send(recipient,sender,subject,body). Este sutil cambio tiene un gran impacto en el código. Pruebalo y deja de escribir pascal en Java 😉