16 de octubre de 2018

Fundamentos de la POO

Hasta ahora básicamente nos hemos limitado a trabajar con datos de muy bajo nivel. Formalmente los únicos objetos con los que hemos tratado han sido los Arrays, las cadenas de texto String y el objeto System.out (que seguramente parece más complicado que los anteriores). En definitiva nos hemos limitado a saber cómo escribir lo básico que podemos encontrar en cualquier lenguaje de programación (variables, operadores, condiciones y bucles).

La orientación a objetos nos va a permitir pensar en soluciones a problemas utilizando objetos tal cual haríamos en el mundo real


Con los Arrays hemos visto la ventaja de contener varios valores en un único valor que los agrupe, pero no deja de ser algo parecido a una lista indexada sin ninguna semántica que nos ayude. Entonces ¿Cómo puedo unir valores relacionados con una misma entidad en un único valor que corresponda con la entidad al completo? La respuesta corta es con los objetos.

NOTA: En esta entrada quiero pintar una visión de conjunto de la nueva parte del curso que empezamos y que se centrará en los objetos. A lo largo de ella vamos a encontrar conceptos desconocidos que no nos deben abrumar, sólo están recogidos aquí para que según vayamos avanzando vayan siendo aclarados, pero que desde hoy podamos apreciar la mentalidad con la que se van a ir descubriendo.

Como desarrolladores contamos con numerosas formas de acercarnos a la solución de un problema. Para evitar el síndrome del papel en blanco, podemos tomar ejemplos de casos de éxito. Estos ejemplos se conocen como paradigmas de programación.

Actualmente el más popular de ellos es la "orientación a objetos" y es una forma muy natural de resolverlo, ya que en la vida real resolvemos problemas con objetos del mundo real y por muy complejo que sea un problema podemos ir uniendo pequeñas soluciones con sus propios objetos que nos ayudan.

Así pues, la Programación Orientada Objetos (POO) se basa en la creación de objetos, su manejo y el "intercambio de mensajes" entre ellos y asume que una solución puede ser resuelta por una serie de objetos que nos ayudarán con distintos problemas relacionados al igual que se podría hacer en la vida real: Imaginemos que necesito una mesa y usaré piezas de madera, una sierra, metro, lápiz, clavos, cola, martillo, etc... cada uno de esos objetos me ayudará en una parte de la construcción de la mesa:
  1. Con el metro y el lápiz marcaré la madera para delimitar las partes que formarán la mesa.
  2. Con la sierra podré recortarlas para tenerlas por separado
  3. Con los clavos y la cola uniré esas partes
  4. Necesitaré el martillo para cuando tenga que usar los clavos
Con esto ya tendría una mesa, pero seguro que en la versión final añadiré lija y puede que tiña la madera y la barnice para que tenga un mejor acabado (esto prodríamos llamarlo como una segunda versión/iteración de nuestra primera solución porque incorpora mejoras)



De aquí tenemos ya presentes conceptos de la POO como por ejemplo:
  1. Madera, Sierra, etc... son Clases y podemos hacernos una idea sobre ellas sólo por su "NombreDeClase" (escrito así porque en Java los nombres de clases se escriben con la sintaxis UpperCamelCase)
  2. Sin embargo no todas las maderas o sierras son iguales:
    1. Hay maderas más duras que otras, su color también es distinto, pueden venir tratadas, hechas tableros y tendrán unas dimensiones. Esos valores que distinguen una pieza de madera de otra se llaman atributos y definen el estado de un objeto:
      1. Algunos de estos pueden ser valores heredados (por las propiedades del árbol del que salió la madera)
      2. Otros serán únicos de cada trozo de madera (sus dimensiones o esa peculiar veta que se ve en un trozo)
      3. Incluso tendrán ciertas limitaciones (una pieza recortada no puede ser más grande que el trozo del que proviene)
    2. Por supuesto que puedo tener dos tableros de madera iguales (equals), con identicos atributos, pero son dos objetos distintos de la misma clase Madera y no son el mismo (!=).
    3. También hay distintas sierras (de mano, circular, etc...) que tendrán sus atributos, que si compro dos iguales tendrán esos atributos iguales pero serán dos objetos distintos de la clase misma clase Sierra igual que en el ejemplo de la clase Madera. Pero lo importante a ver aquí es que todas las sierran tendrán el método "cortar" que realizará una acción que nos convertirá el trozo de madera inicial (que será destruido) en dos distintos con los límites que marcamos con el lápiz, aunque cada sierra lo haga de una forma distinta (polimorfismo)
Por otra parte, hay algunos objetos que se consumen (madera, lápiz, clavos y cola), pero hay otros que me pueden servir para hacer otros muebles (sierra, metro y martillo). De aquí se puede sacar la idea de reutilizar objetos para otras soluciones y que incluso esas soluciones pueden tener relaciones con otra y ser también reutilizadas:
  1. Si en el futuro tenemos que hacer una silla, ya tenemos una serie de clases que sabemos que nos ayudarán a fabricarla
  2. También podremos reutilizar partes de la clase "Mesa" puesto que al ser un mueble comparte atributos (partes que la componen, dimensiones totales, color, etc...) que también estarán presentes en la clase "Silla" y que podemos abstraer estas partes comunes en la clase "Mueble" que nos puede servir en un futuro también para otras soluciones.
  3. Que si un tercero nos proporciona un módulo Tapicero, podremos tapizar nuestros muebles si implementan la interfaz necesaria para ser tapizados.
Nos va a resultar más eficiente contar con objetos que solucionen las partes más pequeñas en que dividimos el problema y que podremos reutilizar, o usar los de terceros


En definitiva, la POO nos va a permitir crear una arquitectura formada por componentes que nos ayudará a ser:
  • más productivos mediante la reutilización de código que será también más fácil de mantener por su encapsulamiento,
  • más fiables al tener esos componentes probados y
  • más flexibles para incorporar nuevas funcionalidades al aprovechar librerías de terceros cuya interfaz nos permita explotar las capacidades de software ajeno.

Con estas ideas en mente (no importan que todavía no estén claras) y las posibilidades que nos ofrecen vamos a empezar a ver todos estos conceptos en las siguientes entradas.

No hay comentarios:

Publicar un comentario

Compárteme

Entradas populares