Apuntes de un evento (POO) Parte 1

Era mi primer evento online. Nunca había dado una clase o evento sin poder ver las caras de las personas que me escuchan. En principio pensé que esto sería malo, pero ya creo que también tiene su parte buena.

Lo malo, no podré saber si están entendiendo o no lo que les estoy contando Lo bueno, no podré saber si tienen esa cara que se les queda a todo el mundo cuando se pregunta, “que tontería está hablando este” 😉

Ya parejos, F5:

Encuesta: Con el objetivo de conocer la opinión de los presentes sobre programar o pensar orientado a objetos, se realizó la siguiente encuesta.

1- ¿Programamos orientado a objetos?
2- Cuando programamos, ¿Pensamos orientado a objetos?

Presentación

En este evento pretendíamos repasar de forma muy elemental los principales conceptos sobre programación orientada a objetos. La mayoría de los lenguajes de programación son hoy en día orientados a objetos. Esto puede traernos confusión al pensar que por programar sobre un lenguaje que sea orientado a objetos, estamos programando orientado a objetos.

Un posible ejemplo de esta confusión es el desarrollo de aplicaciones ASPNET y el Desarrollo en Capas. Podemos crear un proyecto ASPNET donde todo el código esté en un mismo proyecto, donde las consultas se realicen escribiendo directamente el SQL en el code behind y nuestro programa funcionaría, pero ¿Es correcto? NO

Un poco de historia

¿Cómo surge todo esto de la programación orientada a objetos y dónde radica su verdadera importancia?

Todo empezó en la llamada “crisis del software” entre los años 60 y 70.

¿En qué consistía esta crisis?

Los «grandes» grupos de programadores que programaban los «grandes» sistemas para los «grandes” ordenadores tenían serios problemas de organización y productividad. Pocos sistemas lograban terminarse, en pocos se terminaban cumpliendo los requerimientos iniciales y no todos los que se terminaban cumpliéndolos, se usaban según lo planificado.

El problema, que en aquel entonces se llamó de forma incorrecta de “mantenimiento”, consistía en cómo adaptar el software a nuevos requerimientos imposibles de haber sido planificados inicialmente.

La planificación y previsión es contrario a la propia realidad.

Nosotros, las personas, aprendemos y creamos a través de la experimentación, no de la planificación. Si no hay experiencia, no aprendemos, y la experiencia solo llega experimentando y no planificando.

Soy un niño y quiero correr (Experimentar) me caí y me di un golpe (Experiencia) ya sé que no puedo correr sino que debo caminar (enseñanza)

Es imposible y eso creo que todos los sabemos, que exista un proyecto que pueda ser planificado por entero antes de escribir una línea de código, y mucho más imposible, convertir la planificación en una camisa de fuerza en el desarrollo y evolución del sistema.

Aún en la actualidad, se lucha por crear planificaciones adaptables. Las Metodologías ágiles, por ejemplo, intentan planificar un proyecto de software adaptándolo constantemente a los cambios que surgen durante su etapa de desarrollo.

¿Por qué toda esta historia?

¿Es la POO un mejor paradigma que otros? En cierto sentido sí lo es. ¿Es una cura de todos nuestros problemas? No, no lo es. ¿Significa que «crisis del software» desaparecerá? Probablemente no. Y entonces se preguntarán, ¿qué es lo grande de la Programación Orientada a Objetos?

Acercar el ordenador al problema y no al revés. En lugar de tratar de modelar un problema en algo familiar al ordenador, se trata ahora de acercar el ordenador al problema. Se trata en todo momento de modelar los problemas existentes en la vida real

Principales pilares de la programación orientada a objetos.

Encapsulamiento:

Es importante limitar correctamente el acceso a un objeto. Un objeto es un elemento que contiene propiedades y que realiza acciones.

Un avión tiene ruedas, un color, puertas, halas alas. Además realiza acciones como despegar, aterrizar, planear, girar a un sentido u otro. Sobre el avión se realizan acciones que cambian su comportamiento y este, modifica el estado.

Supongamos que el avión contiene un estado que nos indica si está en tierra o en el aire. Jamás deberíamos poder modificar ese estado si no es mediante una acción.

– Estado (En tierra)
– Acción (Despegar). Si despegar fue correcto, cambiar estado (en el aire)
– Estado (En el aire)

Herencia:

Hay que procrear, procreen mucho y así damos continuidad a nuestra especie. Pero, cuidado, no se puede ir haciendo hijos por ahí si no estamos seguros de que le vamos a transmitir y que van a usar todo lo que sabemos.

Esto es herencia. Necesitamos hijos que se apoyen de nuestra experiencia y la apliquen en forma de enseñanza. Lo sé, porque mi padre me lo dijo y listo. Cómo lo supo el padre no importa, eso queda en el encapsulamiento 😉

Piensen en el ejemplo del niño que corre. Los padres constantemente intentan transmitir cuidado, enseñanzas de que no se debe correr para evitar un golpe. El niño no se preocupa cómo sus padres lo aprendieron, “casi siempre” obedecen.

Pero, de nuevo tenemos que tener mucho cuidado. Si un hijo, a pesar de conocer la experiencia del padre termina por no usarla y crear una personalidad propia, entonces ya no existe herencia, sino que serían dos personas totalmente distintas. Dos objetos distintos.

La herencia, entre otras cosas, es para un informático el pan nuestro de cada día. Reutilización, no escriban lo mismo dos veces. El tiempo es dinero y hasta un minuto puede costar caro. Piensen, piensen y piensen. Si hay dos objetos que tienen similar comportamiento, el mantenimiento de los mismos de manera separada multiplica por dos el tiempo para realizarlo.

Cohesión/ Especialización (ver comentarios al final del artículo):

Esto es la especialización de cada objeto. Tenemos que llegar a lograr que cada objeto se especialice solo en lo que sabe hacer, extendernos haría que termináramos mezclando funcionalidad.

La silla, fue diseñada solo para sentarnos. Algunos la usamos como escalera, pero no fue diseñado para eso. Cuando usamos la silla como escalera y nos caemos decimos: claro, era una silla y no una escalera.

El perro es un perro y el gato es un gato, no hay un perro-gato. Un coche es un coche y un avión es un avión. Y si no me creen, intenten volar con un coche.

Los objetos mientras mayor sea su cohesión, mejor podremos definir su comportamiento.

Abstracción:

Aquí pensamos en qué hace y no en cómo lo hace. Dentro de la programación orientada a objeto la Abstracción nos permite definir características del objeto, modelar su comportamiento sin llegar a especificar el cómo lo hace.

En la realidad, el ser humano no piensa en las cosas como un conjunto de pequeñas cosas sino que las entendemos como objetos con comportamientos bien definidos.

Una persona es un objeto con un comportamiento bien definido. Cuando una persona desea desplazarse, el cuerpo responde caminando. En ese momento no pensamos cómo nuestro deseo llegó al cerebro y este envía el mensaje en forma de acción hacia los músculos de los pies para provocar el movimiento. Simplemente, caminamos y eso define el comportamiento.

El principio de abstracción es precisamente esto: Lograr tener objetos con comportamientos bien definidos e irlos dividiendo sucesivamente en conjuntos de subsistemas cada vez más especializados.

El objeto animal es un ejemplo de abstracción, tiene características como edad, sexo, color y realiza acciones como comer, dormir o desplazarse. La especialización de esta abstracción podría ser un objeto perro, gato, paloma o persona, cada nuevo objeto implementa el cómo hará cada acción.

Polimorfismo:

Es la capacidad que permite mantener organizada varias acciones en objetos heredados que aun significando lo mismo, se realizan de manera diferente.

Existen aviones de combate que pueden despegar desde un porta-aviones en el medio del mar, otros que no tienen tal capacidad y lo hacen siempre desde una pista. La acción a realizar es Despegar, pero la manera en que lo hacen es diferente.

En POO, el polimorfismo se aplica cuando necesitamos sobre escribir métodos o atributos llamados de forma idéntica pero con un comportamiento distinto.

No confundir polimorfismo con sobre-carga: Polimorfismo (Entre clases, se resuelve en tiempo de ejecución) Sobre-carga (métodos de la misma clase, se resuelve en tiempo de compilación)

Acoplamiento:

Es la dependencia existente entre objetos para poder funcionar.

La comunicación entre objetos siempre se realiza mediante acciones (llamadas a métodos) y es conocida como comunicación por mensajes. Haz esto, hora tú haz aquello para yo luego poder hacer lo mío.

Si bien es verdad que mientras menos acoplamiento exista entre los objetos, mejor encapsulado quedará el objeto, debemos tener mucho cuidado en no mezclar responsabilidades.

Una tuerca es un objeto con una funcionalidad bien definida: Apretar o asegurar algo. A nadie hasta ahora se le ha ocurrido crear una tuerca que se ajuste por sí misma. A la tuerca, se le hace rosca, que es quien permite el ajuste y por fuera se le da diferentes formas según la herramienta que se desee utilizar posteriormente para ajustar dicha tuerca. Unir la funcionalidad de ambos objetos (tuerca y llave) en uno solo implica que estemos mezclando responsabilidades.

Una manera de darnos cuenta de estas cosas es cuando nuestras clases crecen y crecen y crecen. Si esto pasa, paremos por un instante a pensar si no estamos mezclando funcionalidad de varios objetos en uno solo.

PD: Este artículo continuará con la explicación de los ejemplos utilizados en el evento. De todas formas, pueden descargarse toda la documentación y ver el evento desde la página del grupo de usuarios SNUG

Salu2

Bibliografía utilizada: Programación Orientada a Objetos en C++ – Miguel Katrib Mora.

4 comentarios sobre “Apuntes de un evento (POO) Parte 1”

  1. Gracias por postear aquí este resumen.
    Me apunté pero mi bebe de 2 meses me boicoteó el evento ;-), ahora puedo por lo menos afianzar estos conceptos de POO que tenían muy buena pinta.
    Un saludo.

  2. @Omar

    El articulo es excelente en mi opinion.
    A medida que fui leyendo fui entendiendo cada explicacion por su sencilles y a la vez por su contundencia. Muchas veces es mas importante un articulo asi de pocas palabras pero de gran alcance.
    La bibliografia dice mucho, poco que añadir a la persona-profesor de mis estudios universitarios como es Miguel Katrib (y de miles de estudiantes mas).
    Realmente este articulo seria un buen punto de partida para muchos que entrarian en este mundo de la programacion.
    Una duda, hablando conceptualmente, le llaman «cohesión» a la especialización ?
    Este termino puede llevar a la confusion de conceptos porque no veo la relacion cohesion-especializacion, cohesion es union, compenetracion, atraccion, adhesion, pero «especializacion» …. desde que angulo ?
    Union, adhesion de los atributos-funcionalidad crearia especializacion ? Estoy de acuerdo en lo de la especializacion pero no creo q cohesion sea la palabra de definicion, la misma especializacion creo q aporta la idea.
    PD: Con animo de observacion constructiva, te detallo (dentro de «encapsulamiento») un gazapo en las propiedades del avion, es «alas» y no «halas».
    Mis saludos.
    Alejandro

  3. Hola Alejandro..

    Excelente comentario.. 😉 Primero.. lo siento por esa «h» que se coló en las alas del avión sin querer, corregido.

    Sobre la cohesión, tienes razón de que es un término que pudiera traer confusión. He puesto al lado especialización y que lean acá el razonamiento que haces de la terminología.

    Cuando la usé, pensaba en una cohesión funcional… Que es la que se produce cuando agrupamos unidades de software teniendo en cuenta que todas ellas contribuyen a realizar un mismo fin (especialización en algo). Es decir, cuando todas las unidades agrupadas, trabajando juntas consiguen un objetivo.

    En este caso no vemos al objeto como un subconjunto de pequeñas funcionalidades, sino como un todo capaz de tener un comportamiento bien definido.

    Gracias por el comentario… y sobre el «profe», ya lo has dicho, sobran las palabras. 😉

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *