POO Según Los Manuales

Bien siguiendo con los tutoriales sobre la POO hoy lo veremos a un nivel mas tecnico asi como lo describen en la varias webs.

La POO es un paradigma que tiene sus orígenes desde antes de 1990 (a partir de este año se empieza a popularizar). Por lo tanto no es ninguna excusa (menos como Desarrolladores ) seguir a la fecha desconociendo cómo trabajar con POO o discutiendo si realmente es útil su adopción.

“Los objetos son entidades que combinan estado, comportamiento e identidad”

Fundamental, los beneficios que obtenemos usando este paradigma:
“La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer los programas y módulos más fáciles de escribir, mantener y reutilizar.”

Diferencias con respecto a la Programación Estructurada versus Programación Orientada a Objetos:

la primera se pensó como funcionalidad por un lado y datos por otro, es decir, llamar a una función y pasarle constantemente datos para que los procese, mientras que la POO está pensada para tener todo integrado en el mismo objeto.

“En la programación estructurada sólo se escriben funciones que procesan datos. Los programadores que emplean éste nuevo paradigma, en cambio, primero definen objetos para luego enviarles mensajes solicitándoles que realicen sus métodos por sí mismos.”

Muy importante es tener SIEMPRE en claro los conceptos FUNDAMENTALES, si no los tienes claros cuando programas POO, algo está mal, seguro errarás el camino que define el paradigma: Clase, Herencia, Objeto, Método, Evento, Mensaje, Atributo, Estado Interno, Componentes de un objeto y Representación de un objeto. No dudes en volver a repasarlos todas las veces que lo necesites, por más experto que te consideres, siempre viene bien una relectura de nuestras bases.

Características de la POO: igual que el punto anterior, es fundamental tener claros estos conceptos cada vez que desarrollamos, con principal énfasis en el Principio de Ocultación (que es muy común confundir con Encapsulamiento), lo que explica por qué no deberían existir los atributos públicos ni abusar de los setter/getter (tema que veremos más adelante).

“Empezar a plasmar los objetos en un diseño”

Atributos y comportamiento

“Los atributos y comportamientos pueden ser públicos o privados”
Existirá información y comportamientos que serán conocidos por otros objetos (“acceso público”) y esto permitirá que se pueda generar una interacción entre ellos. También existirá información y comportamientos que serán internos de cada objeto (“acceso privado”) y no serán conocidos por los demás objetos.

Las clases se construyen en la etapa de diseño donde definimos qué es lo que queremos crear. Lo que creamos a partir de ellas es un objeto que “tendrá vida” (será lo que verdaderamente se ejecutará en nuestro sistema) y a la vez “único” (podrán existir muchos objetos del mismo tipo, pero podremos interactuar con ellos e identificarlos de forma única).

Dentro de las definiciones de la clase tenemos los atributos y los comportamientos que tendrá nuestra creación, algunos de ellos serán públicos y otros serán privados. Todo lo que definamos como público será nuestra “conexión” con el exterior y permitirá la interacción entre los objetos. Esta interacción se dará a través de envíos de mensajes entre objetos.

Es necesario que te des una leida de las bases de la programacion Orientada a objetos :

Comenten no sean bayuncos....