Un problema muy grande

via GIPHY

Ya sabemos algunas cosas sobre los principios Orientados a Objetos... ¿Ya estoy listo para poner en mi biografía de Twitter que soy un dev? Para nada. Lo que sabes gracias a que has leído 4 capítulos dista mucho de lo que aprenderías si lo llevaras a la práctica y este capítulo te lo demostrará. En este capítulo se revisitó el código creado en el capítulo 1, sí, el software para vender guitarras de Rick, él quiere, según él, un "pequeño" cambio que al final resulta ser todo menos pequeño. Sin más, vamos allá.

UML sigue siendo cool

Lo primero que salta a la vista en el capítulo es que ya vamos a hacer un poco más formales y vamos a usar diagramas UML para todo pues buena parte del capítulo anterior se trató de este tipo de representaciones. La primera simbología nueva que se nos presenta en la lectura son unas flechas extrañas que tienen punta en forma de triángulo:

De Serna, M. - Transferred from ResearchGate, Dominio público, Enlace

Sí, esa que dice refinement pero, ¿para qué demonios sirven? Bueno, primero te tenemos que presentar las clases abstractas y las interfaces.

Picasso debió programar

via GIPHY

Si el arte abstracto es difícil de entender agárrate de tu asiento porque te vamos a explicar un principio Orientado a Objetos muy particular: la abstracción. Para este punto esperamos que saques tus apuntes de Programación Orientada a Objetos pero estoy casi seguro que no tendrás nada de este tema porque malgastaste tu tiempo diseñando horribles GUI's para que tengas un poco de transfondo de lo que de aquí se te enseñará.

Una clase abstracta es una clase especial de la cual no podrás crear ninguna instancia, es decir, no podrás crear ningún objeto a partir de ella, sin embargo, si podrás definir ciertos métodos que no podrán ser implementados en la clase base pero otros que sí y se llaman métodos abstractos. ¿Confundido? También nosotros. Ya hablando en lenguaje que sí entendemos, las clases abstractas definen métodos y su comportamiento pero no lo implementan, lo que lo implementarán serán sus subclases.

¿Por qué no puedo definir un comportamiento? Bueno, de que puedes, puedes. Por ejemplo, puedes implementar un constructor y que tu subclase lo llame con super y listo, pero lo que nos interesa son los métodos abstractos pues estos métodos no estarán implementados, sólo estarán declarados y su comportamiento lo definirán las clases que se deriven de esta clase abstracta, veamos la siguiente imagen:

De Desconocido - Transferred from sekthDroid, Dominio público, Enlace

¿Lo viste, lo viste? La clase abstracta animal declara el método dibuja e imprime pero... ¿Será lo mismo como se dibujará un elefante y un pato? Va a ser que no. Es aquí donde Elefante se encargará de implementar su propio método dibuja y pato lo hará por igual. ¿Hay algún límite? Por supuesto que no, cada método hará lo que se le venga en gana.

Ok, Picasso no debió programar

Ya entendimos las clases abstractas o al menos eso intentamos pero agárrate ahora de tu abuela y de todo lo que puedas porque ahora vienen las interfaces. Asaaa, que no son tan dramáticas pero me gusta hacerla de emoción, así que pregúntate... Si todos mis métodos serán abstractos y no declararé ni siquiera un constructor... ¿Qué pasa? Bueno, entonces en vez de crear una clase abstracta puedes hacerte de una interfaz. Una interfaz específica el comportamiento pero no su implementación pero, ¿no me estás contando lo mismo que en las clases abstractas? Bueno, un poco, sí. Pero vamos por partes.

De Desconocido - Transferred from Guru99, Dominio público, Enlace

En una interfaz no podrás declarar un comportamiento general para ningún método, esta es la principal diferencia respecto a las clases abstractas en cuánto al código. Si ya nos metemos en asuntos conceptuales cuando implementas una interfaz no estás utilizando herencia de ninguna manera, sólo estarás diciendo qué es lo que se tendrá que hacer sin preocuparte de que haga algo forzosamente. Para mi me queda un poco más claro si pienso en que una interfaz es una plantilla y una clase abstracta es una semi-plantilla. 

Las cosas se ponen difíciles

via GIPHY

Insisto, todo tu conocimiento teórico no te salvará a la hora que tengas ciertas dudas cuando estés programando y como un ejemplo de ello te haré una pregunta, ¿cuándo usarás una interfaz y cuando una clase abstracta? Ambas se parecen bastante y sólo distan de unas cuantas características, ¿qué te dirá cuándo implementar una o la otra? Bueno, eso te lo dirá tu proyecto y el alcance del mismo. Durante la lectura primero se implementaron clases abstractas cuando Rick sólo insistía en añadir otro instrumento que se parecía a una guitarra, en este punto las clases abstractas funcionaban bien pero en cuanto se comenzaron a añadir más y más instrumentos las clases abstractas provocaban más problemas de los que solucionaban y tuvimos que pasar a usar interfaces, ¿ahora lo notas?

Cada proyecto es diferente y no tiene caso intentar explicarte todos los detalles ahora mismo o todas las situaciones que podrían pasarte. Toma nota de lo que crees que te pueda servir y ve directo a la acción, de otro modo nada de lo que leas te será de utilidad. 

Bonus UML

De Desconocido - Transferred from sekthDroid, Dominio público, Enlace

¿Recuerdas que te dije que te explicaría qué eran las flechas raras con un triángulo en la punta? Bueno, sirven para indicar generalización. En este caso nos muestran que una clase, como la clase B heredarán un comportamiento de la clase abstracta A y en otro caso que la clase abstracta A implementará el comportamiento de la interfaz A, ¿lo ves? No es tan complicado. Además, también nos muestra que en UML para indicar que estamos hablando de una clase abstracta tenemos que indicarlo con letras itálicas mientras que para indicar que hablamos de una interfaces tenemos que poner entre 2 corchetes angulares la palabra interface.

Recuerda que siempre puedes visitar la página de O'REILLY y comprar el libro del cual estos post están basados.