¿Qué es la programación orientada a objetos?
La programación orientada a objetos (OOP) es un paradigma de programación. Se basa en la idea de agrupación de datos y funciones relacionados en "islas" de información. Estas islas se conocen como objetos.
Independientemente del paradigma que se use, los programas utilizan la misma serie de pasos para solucionar problemas:
- Entrada de datos: los datos se leen desde cualquier lugar, que podría ser un almacenamiento de datos como un sistema de archivos o una base de datos.
- Procesamiento: los datos se interpretan y, posiblemente, se modifican para representarlos.
- Salida de datos: los datos se presentan para que un usuario físico o un sistema pueda leerlos e interactuar con ellos.
Diferencias entre OOP y la programación mediante procedimientos
Ahora se intentará definir qué es OOP, para lo que se comparará con otro paradigma: la programación mediante procedimientos. La programación mediante procedimientos intenta resolver un problema determinado mediante la llamada a procedimientos, también conocidos como funciones o métodos. Se crean funciones y variables para abordar las distintas fases que se describen en los pasos anteriores.
El paradigma de OOP no es diferente en ese aspecto. Destaca por su visión del mundo. En comparación con la programación mediante procedimientos, la OOP retrocede un paso y examina una visión general más amplia. En lugar de trabajar con los datos y tomarlos de una fase a la siguiente, la OOP intenta entender el mundo en el que operan los datos. Para ello, modela lo que ve.
Modelado de OOP: identificación de conceptos
Durante la fase de modelado, examinará la descripción de un dominio e intentará analizar el texto sobre lo que sucede. El primer paso consiste en identificar a los actores. Se denominan actores porque actúan y realizan una acción. Por ejemplo, una impresora (actor) imprime (acción).
Una vez que ha identificado los actores, se examina qué hacen, su comportamiento. Después, se examinan las descripciones de los actores y los datos necesarios para llevar a cabo la acción. Los actores se convierten en objetos, los rasgos se codifican como datos en los objetos y los comportamientos son funciones que también se agregan al objeto.
El concepto es que los datos de los objetos se pueden modificar mediante una llamada a funciones en los propios objetos. También existe el concepto de que los objetos interactúan entre ellos para lograr un resultado tangible.
Ventajas de la OOP
¿Por qué usar la OOP? ¿Por qué no usar otro paradigma? Para ser claros, la OOP no es mejor ni peor que otros paradigmas. Tiene sus ventajas e inconvenientes. OOP tiene algunas ventajas agradables, por ejemplo:
- Encapsulación de datos: la encapsulación de datos consiste en ocultar los datos del resto del sistema y solo permitir el acceso a partes de este. El motivo es que los datos tienen un estado y ese estado puede estar formado por una o más variables. Si hay que cambiar estas variables al mismo tiempo, debe protegerlas y permitir solo el acceso a través de métodos públicos para que los cambios se realicen de una manera predecible. La OOP tiene mecanismos como los niveles de acceso, donde los datos de un objeto solo son accesibles para el propio objeto, o bien pueden estar disponibles de forma pública.
- Simplicidad: la creación de grandes sistemas es una tarea compleja, con muchos problemas que resolver. La capacidad de dividir la complejidad en problemas más pequeños, en objetos, significa que puede simplificar la tarea global.
- Facilidad de modificación: cuando se basa en objetos y modela el sistema con ellos, es más fácil realizar el seguimiento de qué partes del sistema se deben modificar. Por ejemplo, es posible que tenga que corregir un error o agregar una característica nueva.
- Capacidad de mantenimiento: en general, el mantenimiento del código es difícil y con el tiempo se complica más. Requiere disciplina en forma de una nomenclatura correcta y una arquitectura clara y coherente, entre otras consideraciones. El uso de objetos facilita la búsqueda de un área concreta del código que necesita mantenimiento.
- Reusabilidad: puede usar la definición de un objeto muchas veces en muchas partes del sistema o, potencialmente, también en otros sistemas. Al reutilizar el código, se ahorra tiempo y dinero, porque así se escribe menos código y se llega más rápido al destino.
Modelado de un sistema de OOP
El software se suele escribir para abordar la necesidad de que algo sea más rápido, eficiente y menos propenso a errores. Los usuarios simplemente no pueden competir con el software cuando se trata de acelerar un proceso en determinados casos. El uso de OOP se basa tanto en modelar como en escribir el código para implementar su lógica. El modelado consiste en aprender a identificar a los actores, los datos necesarios y el tipo de interacción que se produce. Puede modelar un sistema simplemente mediante la lectura de su descripción.
Caso práctico de un sistema de administración de facturas
Ahora se examinará un flujo manual al que se enfrentan muchas empresas: la administración de facturas. Muchas empresas reciben facturas y deben pagarse a tiempo. El retraso en los pagos supone recargos, lo que provoca que se pierda dinero. Antes de que una factura se pueda pagar, se debe procesar. Es habitual que una factura pase por varias manos antes de que se registre y se realice el pago.
Normalmente, el proceso comienza con una fase de ordenación inicial en la que la factura se envía al departamento adecuado. A continuación, se comprueba que la factura sea correcta y, después, la aprueba alguien que tenga el nivel de autorización adecuado. Por último, se paga la factura. En el caso de una pequeña empresa, es posible que el propietario realice todos los pasos. En una gran empresa, puede haber muchos individuos y procesos implicados, lo que hace que la administración de facturas sea una actividad compleja.
¿Qué tiene que ver esta descripción con la OOP? Si tomara el flujo de trabajo anterior, que suele ser manual, y lo convirtiera en software escrito, lo primero que haría es intentar modelar el sistema. En el contexto de la administración de facturas, puede empezar a ver los actores (objetos), los comportamientos y los datos mediante la lectura de una descripción del dominio del problema.
Si piensa en que el dominio descrito tiene fases, entrada, procesamiento y salida, puede empezar a rellenar las cosas como se indica en la tabla siguiente:
| Fase | Qué |
|---|---|
| Entrada | Factura |
| Processing | Ordenación, aprobación, rechazo |
| Output | Payment |
En la tabla anterior se describe lo que sucede en cada fase. Ha podido encontrar los datos, lo que sucede con los datos durante el procesamiento y el resultado final, que es un pago. Llegado a este punto, todavía puede resolver el flujo de trabajo del sistema de administración de facturas con cualquier paradigma que prefiera. ¿Cómo se lleva desde aquí a la OOP?
Búsqueda de objetos, datos y comportamiento
Puede encontrar los diferentes artefactos del sistema si formula las preguntas siguientes:
- ¿Quién interactúa con quién?
- ¿Quién hace qué a quién?
Teniendo en cuenta estas preguntas, puede idear afirmaciones. Ahora se resaltarán los distintos artefactos en estas afirmaciones para que quede claro qué elementos son importantes para el sistema.
El servicio de correoentrega unafactura al sistema.
La factura se ordena por un código de referencia, o bien de forma manual mediante un clasificador para garantizar que llegue al departamento correcto.
Un aprobadoraprueba o rechaza la factura en función de factores como su corrección y la cuantía del importe (por ejemplo).
Un procesador de pagospaga la factura mediante la información de pago proporcionada.
Ahora puede extraer objetos, datos y comportamiento de las frases y organizarlos en una tabla, de la siguiente manera:
| Fase | Actor | Comportamiento | data |
|---|---|---|---|
| Entrada | Servicio de correo | Entrega | Factura |
| Entrada | Sistema | Recibe | Factura |
| Processing | Clasificadores o sistema | Ordena o enruta | Factura (código de referencia) |
| Processing | Aprobador | Aprueba o rechaza | Factura (importe) |
| Output | Procesador de pagos | Paga | Factura (información de pago) |
La descripción inicial del sistema de administración de facturas ha sufrido muchos cambios. Se han encontrado actores (objetos). Se han identificado datos importantes y se han agrupado con objetos identificados. También se ha encontrado el comportamiento, que aclara todavía más qué actores (objetos) interactúan entre sí. Como resultado, ha podido identificar quién tiene un comportamiento concreto con quién. Llegado a este punto ha realizado un análisis inicial, lo que es un inicio excelente. Pero todavía queda la duda de cómo se convierte este análisis en código. La respuesta a esa pregunta es lo que se resolverá a lo largo de este módulo.
Nota:
Probablemente un sistema de administración de facturas real sea mucho más complejo y dependa de muchos más datos y lógica. La capacidad de modelar un sistema de esta manera significa que tiene un enfoque estructurado para abordar el problema.