Programación Orientada a Objetos

La programación orientada a objetos es un tipo de codificación en la cual se

utilizan objetos como datos prediseñados para obtener los resultados. Los objetos
son datos almacenados en la memoria que poseen ciertos atributos (altura,
ancho, color etc.) con el fin de realizar una función dada en respuesta a un evento.

Muchos de estos objetos permiten la agrupación en bibliotecas o librerías, sin

embargo, la programación orientada a objetos permite al usuario la creación de
nuevas librerías. El uso de esta programación se popularizó en la década de los
90’ en un lenguaje diseñado para hacer simulaciones llamado “Simula 67”.

Componentes de la Programación Orientada a Objetos

Clase: Definiciones de las propiedades y comportamiento de un tipo de objeto

concreto. La instanciación es la lectura de estas definiciones y la creación de un
objeto a partir de ella.

Objeto: Instancia de una clase. Entidad provista de un conjunto de propiedades o

atributos (datos) y de comportamiento o funcionalidad (métodos), los mismos que
consecuentemente reaccionan a eventos.

Método: Algoritmo asociado a un objeto (o a una clase de objetos), cuya

ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de
vista del comportamiento, es lo que el objeto puede hacer.

Evento: Es un suceso en el sistema (tal como una interacción del usuario con la
máquina, o un mensaje enviado por un objeto). El sistema maneja el evento
enviando el mensaje adecuado al objeto pertinente. También se puede definir
como evento la reacción que puede desencadenar un objeto; es decir, la acción
que genera.

Atributos: Características que tiene la clase.

Mensaje: Una comunicación dirigida a un objeto, que le ordena que ejecute uno
de sus métodos con ciertos parámetros asociados al evento que lo generó.

Características de la Programación Orientada a Objetos

Abstracción: El proceso de abstracción permite seleccionar las características

relevantes dentro de un conjunto e identificar comportamientos comunes para
definir nuevos tipos de entidades en el mundo real. La abstracción es clave en el
proceso de análisis y diseño orientado a objetos, ya que mediante ella podemos
llegar a armar un conjunto de clases que permitan modelar la realidad o el
problema que se quiere atacar.
Encapsulamiento: Significa reunir todos los elementos que pueden considerarse
pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite
aumentar la estructura del diseño de los componentes del sistema.

Polimorfismo: Comportamientos diferentes, asociados a objetos distintos, pueden

compartir el mismo nombre; al llamarlos por ese nombre se utilizará el
comportamiento correspondiente al objeto que se esté usando.

Herencia: Las clases no se encuentran aisladas, sino que se relacionan entre sí,
formando una jerarquía de clasificación. Los objetos heredan las propiedades y el
comportamiento de todas las clases a las que pertenecen. La herencia organiza y
facilita el polimorfismo y el encapsulamiento, permitiendo a los objetos ser
definidos y creados como tipos especializados de objetos preexistentes.

Modularidad: Se denomina "modularidad" a la propiedad que permite subdividir

una aplicación en partes más pequeñas llamadas módulos, cada una de las cuales
debe ser tan independiente como sea posible de la aplicación en sí y de las
restantes partes. Estos módulos se pueden compilar por separado, pero tienen
conexiones con otros módulos. Al igual que la encapsulación, los lenguajes
soportan la modularidad de diversas formas.

Recolección de basura: La recolección de basura es la técnica por la cual el

entorno de objetos se encarga de destruir automáticamente, y por tanto
desvincular la memoria asociada, los objetos que hayan quedado sin ninguna
referencia a ellos. Esto significa que el programador no debe preocuparse por la
asignación o liberación de memoria, ya que el entorno la asignará al crear un
nuevo objeto y la liberará cuando nadie lo esté usando.

Las características de orientación a objetos fueron agregadas a muchos lenguajes

existentes durante ese tiempo, incluyendo Ada, BASIC, Lisp más Pascal, entre
otros. La adición de estas características a los lenguajes que no fueron diseñados
inicialmente para ellas condujo a menudo a problemas de compatibilidad y en la
capacidad de mantenimiento del código. Los lenguajes orientados a objetos
"puros", por su parte, carecían de las características de las cuales muchos
programadores habían venido a depender. Para saltar este obstáculo, se hicieron
muchas tentativas para crear nuevos lenguajes basados en métodos orientados a
objetos, pero permitiendo algunas características imperativas de maneras
"seguras". El lenguaje de programación Eiffel de Bertrand Meyer fue un temprano
y moderadamente acertado lenguaje con esos objetivos, pero ahora ha sido
esencialmente reemplazado por Java, en gran parte debido a la aparición
de Internet y a la implementación de la máquina virtual Java en la mayoría
de navegadores web. PHP en su versión 5 se ha modificado; soporta una
orientación completa a objetos, cumpliendo todas las características propias de la
orientación a objetos.

Qué es MVC (Modelo, Vista, Controlador)

En líneas generales, MVC es una propuesta de diseño de software utilizada para

implementar sistemas donde se requiere el uso de interfaces de usuario. Surge de
la necesidad de crear software más robusto con un ciclo de vida más adecuado,
donde se potencie la facilidad de mantenimiento, reutilización del código y la
separación de conceptos.

Modelos

Es la capa donde se trabaja con los datos, por tanto contendrá mecanismos para
acceder a la información y también para actualizar su estado. Los datos los
tendremos habitualmente en una base de datos, por lo que en los modelos
tendremos todas las funciones que accederán a las tablas y harán los
correspondientes selects, updates, inserts, etc.

No obstante, cabe mencionar que cuando se trabaja con MCV lo habitual también
es utilizar otras librerías como PDO o algún ORM como Doctrine, que nos
permiten trabajar con abstracción de bases de datos y persistencia en objetos. Por
ello, en vez de usar directamente sentencias SQL, que suelen depender del motor
de base de datos con el que se esté trabajando, se utiliza un dialecto de acceso a
datos basado en clases y objetos.

Vistas

Las vistas, como su nombre nos hace entender, contienen el código de nuestra
aplicación que va a producir la visualización de las interfaces de usuario, o sea, el
código que nos permitirá renderizar los estados de nuestra aplicación en HTML.
En las vistas nada más tenemos los códigos HTML y PHP que nos
permite mostrar la salida.

En la vista generalmente trabajamos con los datos, sin embargo, no se realiza un

acceso directo a éstos. Las vistas requerirán los datos a los modelos y ellas se
generará la salida, tal como nuestra aplicación requiera.

Controladores

Contiene el código necesario para responder a las acciones que se solicitan en la

aplicación, como visualizar un elemento, realizar una compra, una búsqueda de
información, etc.
En realidad es una capa que sirve de enlace entre las vistas y los modelos,
respondiendo a los mecanismos que puedan requerirse para implementar las
necesidades de nuestra aplicación. Sin embargo, su responsabilidad no es
manipular directamente datos, ni mostrar ningún tipo de salida, sino servir de
enlace entre los modelos y las vistas para implementar las diversas necesidades
del desarrollo.

¿Cómo funciona el MVC?

El usuario realiza una solicitud a nuestro sitio web. Generalmente estará

desencadenada por acceder a una página de nuestro sitio. Esa solicitud le llega al
controlador.

El controlador comunica tanto con modelos como con vistas. A los modelos les
solicita datos o les manda realizar actualizaciones de los datos. A las vistas les
solicita la salida correspondiente, una vez se hayan realizado las operaciones
pertinentes según la lógica del negocio.

Para producir la salida, en ocasiones las vistas pueden solicitar más información a
los modelos. En ocasiones, el controlador será el responsable de solicitar todos
los datos a los modelos y de enviarlos a las vistas, haciendo de puente entre unos
y otros. Sería corriente tanto una cosa como la otra, todo depende de nuestra
implementación; por eso esa flecha la hemos coloreado de otro color.

Las vistas envían al usuario la salida. Aunque en ocasiones esa salida puede ir de
vuelta al controlador y sería éste el que hace el envío al cliente, por eso he puesto
la flecha en otro color.

Lógica de negocio del MCV

Hay un concepto que se usa mucho cuando se explica el MVC que es la "lógica de
negocio". Es un conjunto de reglas que se siguen en el software para reaccionar
ante distintas situaciones. En una aplicación el usuario se comunica con el sistema
por medio de una interfaz, pero cuando acciona esa interfaz para realizar acciones
con el programa, se ejecutan una serie de procesos que se conocen como la
lógica del negocio. Este es un concepto de desarrollo de software en general.

La lógica del negocio, aparte de marcar un comportamiento cuando ocurren cosas

dentro de un software, también tiene normas sobre lo que se puede hacer y lo que
no se puede hacer. Eso también se conoce como reglas del negocio. Bien, pues
en el MVC la lógica del negocio queda del lado de los modelos. Ellos son los que
deben saber cómo operar en diversas situaciones y las cosas que pueden permitir
que ocurran en el proceso de ejecución de una aplicación.
Por ejemplo, pensemos en un sistema que implementa usuarios. Los usuarios
pueden realizar comentarios. Pues si en un modelo nos piden eliminar un usuario
nosotros debemos borrar todos los comentarios que ha realizado ese usuario
también. Eso es una responsabilidad del modelo y forma parte de lo que se llama
la lógica del negocio.

Programación Orientada a Aspectos

La Programación Orientada a Aspectos (POA): es un paradigma de programación

relativamente reciente cuya intención es permitir una adecuada modularización de
las aplicaciones y posibilitar una mejor separación de conceptos. Gracias a la POA
se pueden capturar los diferentes conceptos que componen una aplicación en
entidades bien definidas, de manera apropiada en cada uno de los casos y
eliminando las dependencias inherentes entre cada uno de los módulos.

De esta forma se consigue razonar mejor sobre los conceptos, se elimina la

dispersión del código y las implementaciones resultan más comprensibles,
adaptables y reusables. Varias tecnologías con nombres diferentes se encaminan
a la consecución de los mismos objetivos y así, el término POA es usado para
referirse a varias tecnologías relacionadas como los métodos adaptivos, los filtros
de composición, la programación orientada a sujetos o la separación
multidimensional de competencias.

La programación orientada a objetos (POO) supuso un gran paso en la ingeniería

del software, ya que presentaba un modelo de objetos que parecía encajar de
manera adecuada con los problemas reales. La cuestión era saber descomponer
de la mejor manera el dominio del problema al que nos enfrentáramos,
encapsulando cada concepto en lo que se dicen llamar objetos y haciéndoles
interactuar entre ellos, habiéndoles dotado de una serie de propiedades. Surgieron
así numerosas metodologías para ayudar en tal proceso de descomposición y
aparecieron herramientas que incluso automatizaban parte del proceso. Esto no
ha cambiado y se sigue haciendo en el proceso de desarrollo del software. Sin
embargo, frecuentemente la relación entre la complejidad de la solución y el
problema resuelto hace pensar en la necesidad de un nuevo cambio. Así pues,
nos encontramos con muchos problemas donde la POO no es suficiente para
capturar de una manera clara todas las propiedades y comportamientos de lo que
queremos dotar nuestra aplicación. Así mismo, la programación
procedural tampoco nos soluciona el problema. Por lo que ante tales problemas,
se utiliza la POA.

Caracteristicas de POA

De la consecución de estos objetivos se pueden obtener las siguientes ventajas:

1. Un código menos enmarañado, más natural y más reducido.
2. Una mayor facilidad para razonar sobre las materias, ya que están
separadas y tienen una dependencia mínima.
3. Más facilidad para depurar y hacer modificaciones en el código.
4. Se consigue que un conjunto grande de modificaciones en la definición de
una materia tenga un impacto mínimo en las otras.
5. Se tiene un código más reusable y que se puede acoplar y desacoplar
cuando sea necesario.