Fundamentos de la programación orientada a objetos

Antes de realizar cualquier tipo de codificación (o ver el cursor parpadeante en la pantalla de nuestro ambiente de desarrollo) sin tener en mente lo que vamos a realizar, tenemos que comprender el problema, luego planificar la solución, y luego comenzar con la construcción de la pieza de software.

Metodologías de desarrollo

¿Hay una metodología que me permita de manera óptima la realización de un programa?.

La respuesta a la pregunta anterior es no, ya que existen actualmente muchas metodologías de desarrollo para diversas necesidades. Recordar que no existe sólo un tipo de software.

La primera metodología usada fue la llamada “en cascada”, la cual consistía en que pasábamos a la siguiente etapa de desarrollo, sólo si la etapa actual estaba realizada. Lamentablemente esta metodología actualmente no funciona. Los requerimientos del cliente van en constante cambio, lo que sugiere volver a etapas anteriores y así sucesivamente.

Por otro lado, tenemos el enfoque ágil e iterativo que actualmente es el más utilizado. En cada uno de ellos haremos análisis, diseño y programación. Esto lo repetiremos varias veces en cada etapa.

Lenguajes orientados a objetos

Antes de la aparición de los lenguajes orientados a objetos, existían lenguajes de bajo nivel los cuales se estructuraban por código línea a línea. A medida que los programas se hicieron más y más grandes, estos lenguajes se veían limitados.

En los lenguajes orientados a objetos cada objeto posee sus propios datos y su propia lógica. Estos objetos se comunican entre sí para crear grandes proyectos con una mayor simplicidad.

Algunos de estos lenguajes son C++, C#, Perl, PHP, Python, Java, Ruby, VB.net y muchos más.

¿Qué es un objeto?

Para responder esta pregunta debemos analizar que es un objeto en el mundo real.

Los objetos poseen características inherentes que los hacen únicos. Una taza de café puede estar llena o vacía, una manzana puede ser verde o roja, una copa de vino puede ser grande o pequeña. Estas características son el estado de un objeto, como su color, tamaño, forma, etc. Cada objeto posee un estado que lo define y que es distinto al de otro objeto. Si apagamos una ampolleta, esto no significa que apagaremos todas las ampolletas del mundo.

Además cada objeto posee un comportamiento (acciones que pueden realizar), un perro ladra, una cuenta de banco permite realizar un depósito, un balón se mueve, un televisor se enciende y apaga, etc.

Los objetos no necesariamente deben ser objetos físicos.

Los objetos no necesariamente deben ser visibles.

Clase

Las clases describen como serán nuestros objetos. Es una especie de plano el cual es usado para construir nuestro objeto.

Instancias

El proceso de creación de objetos se denomina instanciación. Cada objeto puede poseer ilimitado números de instancias las cuales representan entidades diferentes. En este caso podemos crear N objetos Persona los cuales poseerán diferentes características que los hará únicos.

Muchas clases ya han sido creadas para satisfacer necesidades simples como generar una fecha, conectarse a una red, etc. Están clases están almacenadas en librerías de clases, más conocidas como frameworks de desarrollo, las cuales poseen funciones adicionales.

·         Java Class Library

·         .NET Framework

·         C++ Standard Library

Es momento de hablar sobre las características principales de la programación orientada a objetos.

Abstracción

Nos centramos en las características genéricas de un objeto y no en un ejemplo concreto.

Por ejemplo si decimos auto, nuestra mente visualiza un auto verdad?. Esta imagen abstracta no está ligada a ninguna propiedad en particular. No hemos dicho el auto rojo, o el auto de 4 puertas, solo hemos dicho auto. Eso es lo que hace la abstracción. Nos centramos en las características generales y no entidades definidas.

Encapsulamiento

Ocultamiento de información. Cada objeto sólo debe comunicarse con otro objeto sólo mediante métodos, y prohibir el acceso a propiedades directamente. Esto nos da mayor modularidad y mayor seguridad en nuestra aplicación.

Los atributos de clases deben ser siempre privados. 

Herencia

Re utilización de código. Una clase hereda de otra y al mismo tiempo hereda todo lo que lleva consigo, propiedades y métodos. Además puede agregar nuevas características a la subclase.

Clase > Subclase

Clase padre > Clase hija

Podemos afirmar que una persona es un mamífero, y que un perro es un mamífero.

Polimorfismo

El término de polimorfismo se refiere a que una clase puede tomar diferentes formas. O sea, este mecanismo permite invocar operaciones idénticas con respecto a su interfaz padre, pero con una implementación diferente en la clase hija.

Como dijimos anteriormente, una subclase puede heredar todo lo que tiene su clase padre, y a su vez, modificar éstos últimos. Este y los demás temas hablados en esta entrada del blog, serán vistos con mayor profundidad en la sección de Java. 

Proceso de diseño de Software

Para realizar un trabajo correcto, debemos seguir los siguientes procedimientos:

• Tomar requerimientos del cliente (lo que debe hacer nuestra aplicación)
• Describir la aplicación
• Identificar los objetos principales
• Identificar las interacciones entre nuestros objetos
• Crear nuestro diagrama de clases

Requisitos funcionales

Se refiere a lo que la aplicación en sí debe hacer, definiendo las características y capacidades del software a desarrollar.

Requisitos no funcionales

Se refiere a temas no realizadas con el desarrollo, ya sea el cumplimiento de leyes, que soporte se le dará y cuan a menudo, cual será su rendimiento óptimo, que se hará en caso de fallas, etc.

UML (Lenguaje unificado de modelado) 

Este lenguaje se encarga de conceptualizar nuestras clases, objetos, paquetes, etc. en un diagrama que es mucho más entendible para un trabajo más rápido. Serán nuestros planes que nos servirán para decirnos que debemos hacer.

Casos de uso

Los casos de uso sirven para representar la interacción del usuario con el sistema, y como realiza diferentes acciones dentro del mismo.

Los diagramas de casos de uso están estructurado con los siguientes elementos:

• Caso de uso
• Actor
• Relaciones 

Caso de uso: Es una tarea específica que se realiza mediante un agente externo, ya sea el propio actor, un actor de otro caso de uso, o incuso un sistema propiamente tal.

Posee un titulo (cual es el objetivo), un actor (quién lo ejecuta), y un escenario (cómo llegar al objetivo).

Actor: Es un rol que un usuario desempeña en el sistema. No necesariamente debe ser una persona, sino que es un ejecutante genérico de algún caso de uso.

Relaciones: Para unir nuestros actores con sus respectivos casos de uso debemos generar una relación que determine qué y cómo se ejecutará dicha operación.

Escenarios

Al determinar los escenarios de nuestros casos de uso, debemos hacer énfasis en el objetivo del actor en el sistema, y obviar escenarios que no correspondan a ello.

Por ejemplo, tenemos una aplicación mobile para pedir comida rápida a domicilio. Para llegar a realizar un pedido debemos de registrar nuestros datos para que los dueños del restaurant sepan donde vivimos y realicen el trayecto con éxito. ¿Cuál es el objetivo del usuario, registrar sus datos o pedir comida a casa?. 

No debemos crear casos de uso que no contribuyan con el objetivo principal del usuario.

Diagrama de casos de uso

Es un tipo de diagrama UML encargado de ilustrar los diferentes casos de uso y actores, mostrando una perspectiva global de los miembros y sus interacciones.

Historias de usuario

Una historia de usuario es más corto que un caso de uso. Se describe solo un pequeño escenario centrado en el usuario y su objetivo. Se escriben en tarjetas con contenido breve.

Estructura:

·         Cómo… (tipo de usuario)

·         Quiero… (objetivo)

·         Para… (razón o fin)

Como usuario

Quiero ver el listado de productos disponibles

Para poder comprar una camisa 

Modelo conceptual del sistema

Tenemos que identificar los objetos principales, refinarlos, y por último dibujarlos en un diagrama.

Nos enfocaremos en la construcción orientada a objetos.

•  Identificar los sustantivos escritos en nuestro escenario de caso de uso
•  Crear una lista con los sustantivos seleccionados y eliminar duplicidades o sustantivos los cuales sean propiedades de un objeto y no un objeto en sí
• Luego creamos las clases con los sustantivos seleccionados

Definir responsabilidades

Éstos serán los comportamientos que se convertirán en métodos. Buscaremos los verbos para recoger todas las responsabilidades. 

Las responsabilidades deben estar distribuidas entre las diferentes clases. Una clase que realiza una acción, no significa que sea responsable de esa acción.

Hay que evitar las clases dios, o clases sistema.

Tarjetas CRC

Las tarjetas CRC definen cuáles serán las responsabilidades de una clase y sus clases colaboradoras. Son creadas en papel y se discuten entre el equipo de desarrollo.

Podemos tomar las tarjetas creadas y ponerlas en un mesón para detectar sus interacciones.

Diagramas de clase

Evitar estructuras de datos planas al escribir demasiadas propiedades sin métodos (responsabilidades) que los completen y/o utilicen.

Miembros estáticos

Son variables o métodos compartidos que no dependen de un objeto en particular, sino que depende de la clase.

Ejemplo: private static final cargo = 25000;

Esta variable puede ser accedida por distintos objetos y su valor será igual para todos. Existirá solo una copia de ésta.