¿Te has escuchado? Hola, buenas tardes. Sí, te escucho. Ah, estupendo.
Muy bien. Pues que estás matriculado, ¿no? ¿Cómo? Estás matriculado,
¿no? Sí, sí, estoy matriculado, sí. Ah, no sé, como me salía la de la
sala de espera esa. No te entiendo bien. O sea, sí te escucho, pero no
sé. ¿Tú me oyes bien a mí? Sí, sí, yo te oigo bien. No, que salía lo
de la sala de espera, pero nada, ya estoy con el tío. ¿Tienes una
compañera, no? María Lourdes, ¿sabes? Parece que sí. Vale, vale, vale.
Sí. Vale, genial. A ver, voy a cerrar un momento la puerta, que parece que
no ha venido nadie en persona. Voy a apagar también un monitor. Vale, si
hemos empezado un poco tarde, tengo otra tutoría antes de programación de
los objetos. Si se han... Siempre tienen muchas dudas y muchas cosas. Y
el... La semana pasada, bueno, ya lo veríais, ¿no? Que no... Que no se
pudo omitir esto porque estaba caído el inteta. Sí, yo intenté empezar,
pero fue imposible. Sí, sí, efectivamente. Bueno, no os preocupéis. Ya
podemos empezar con esto. ¿Tenéis alguna duda o alguna pregunta? ¿O os
explico un poco cómo va la asignatura de eso? Vale, sí. ¿Puedes seguir
explicando cómo realmente vas a afrontar o cómo vas a planificar estos
días? Vale, pues... Bueno, yo estoy abierto ahí a vuestras dudas y
sugerencias. Tenemos la asignatura, pues digamos que profundiza un poco los
conceptos de la de programación orientada a objetos. Y se añaden sobre
todo los patrones de diseño, ¿no? Entonces, el año pasado cambiaron el
libro, que ahora es el de Brower. Y son 20 o 23 patrones de diseño lo que
hay. Y también, ¿qué antes había? Antes había un... porque han
cambiado un poco también el escenario. Porque antes había como una
revisión de conceptos de Saba y no sé qué. A ver, espera que me lo estoy
compartiendo. Vale, ahora lo veis, ¿no? Los patrones de diseño, los
diagramas UML, bueno, que eso viene incluido ahí con los patrones. La
arquitectura software, el patrón modelo vista contemporáneo. Controlador,
diseño de interfaz de usuario, componentes y gestores de disposición,
programación orientada, eventos. Esto antes no estaba así, pero bueno. Y
la parte 2, que son los patrones de diseño, patrones estructurales y
patrones de comportamiento. Vale, pues, no sé, a mí me parece rarísimo
este enfoque, ¿no? Porque, por ejemplo, aquí viene el tema 3, el modelo
vista controlador. Y el modelo vista controlador, pues depende de un
montón de... De patrones de estos, de los temas 5, 6 y 7. O sea, que no
tiene mucho sentido hablar del modelo vista controlador hasta que no se ha
dado esto, ¿no? La verdad, y el diseño de interfaz de usuario, pues lo
mismo. Porque son... Tiene patrones de diseño a chorro y se ven en los
otros temas. Pero bueno, y los diagramas, pues cuando ves los... Cada
patrón, pues ves también los diagramas que tiene. En fin. Hay un vídeo
de presentación, ya me pasé, no se veía. No se veía, no se veía, no se
veía. Entonces ahí se puede buscar la asignatura y ver si hay grupos
disponibles y apuntarse a un grupo. Entonces yo creo que seguramente
todavía no están disponibles los grupos, pero lo estarán. Seguramente el
mes que viene. Entonces la idea es que hay que hacer una sesión de
asistencia obligatoria, tenéis que firmar un papelito, que son unas tres
horas, y entonces ahí os explican todo lo que tengáis que saber sobre la
práctica, pues os lo tenéis que explicar ahí, porque luego el escritor
que os haya tocado de práctica es el que va a corregir la práctica. Y
básicamente sobre la práctica eso es lo que os puedo contar del
enunciado, y hasta ahí no era una cosa... ¿Algo del campo? No me acuerdo,
estuve viendo el enunciado del otro día, pero al final como lo que
preguntas son los patrones y todo eso. Y es muy curioso porque... Está en
el temario lo de las interfaces gráficas de usuario, pero luego en la
práctica no se pide cada una de las interfaces gráficas de usuario, te
dice que es optativo, pero realmente no viene ninguno de los tres niveles
que comentan, ¿no? A ver... Sí, estas son las cosas estas del campo. Un
poco muy de lo que antes era la informática de gestión, ¿no? Sí, o sea,
¿no aparece como que tengas que implementar nada gráfico? No, quedan.
Quedan aquí unos niveles no pasados, porque las partes, sí, las partes
esas. Primera parte, la de la vista controladora de los servers, la gran
clase. La segunda, el plico de patrón strategy. El tercero, el abstract
factory y esto. La cuarta parte de los servers y bla, bla, bla. Y bueno, es
que sí, que yo no puedo... Es que me lo leí, no vi que dijera nada. O
sea, se supone que la interfaz debe ser así como un modo texto, ¿no? Pero
es que si quiere uno, pues supongo que puede hacer la interfaz gráfica,
¿no? Eso sí aporta mucho. un poco porque no debería ser muy complicado
hace un poco rollo pero bueno entonces no sé yo si queréis os puedo
proponer ahí revisar primero los patrones de diseño para ir entendiendo
un poco lo que hay que hacer en cada cosa ¿no? ¿cómo lo veis? vale, vale
vale pues a ver a ver, cada uno de estos patrones ¿hace falta tener los
conocimientos de los temas anteriores? ¿de qué? ¿de lo de Java? sí,
bueno de Java se sobre entiende que sí pero de los temas o sea, están
puestos con el tema 5, 6, 7 o una cosa así ¿es necesario estudiar los
temas anteriores? no vamos, eso es diferente a ver, se pueden estudiar de
forma independiente totalmente es que independiente no, es que el orden
está mal hay que empezar por aquí si no lo otro es imposible vale,
gracias ay la leche que no que no quiero tener esta cuenta vamos a copiar
aquí pues el libro es un poco un poco extraño porque es el libro de la
recomendada porque está en español pero el libro es el que me gusta a mí
es el que es más o menos el libro y eso y que es el libro famoso de
patrón de diseño a ver hay un libro más famoso que era hasta el año
pasado el libro oficial que es el design pattern de gamba y compañía este
bueno esto está en inglés pero vamos la versión en español que era lo
que se utilizaba el año pasado pero claro este libro es muy antiguo es un
libro del 94 y era un puro considerable entonces lo cambiaron por el libro
de Drawer que hace desarrollo de una aplicación pero la verdad es que es
bastante tostón entonces yo casi recomiendo más seguir esto pero bueno
entonces el libro el capítulo 1 sería es el pattern strategy empieza por
ahí muy bien entonces ahí lo que empieza es con una aplicación para
simular pattern que es un programador que trabaja en una empresa de
orientación a objetos y ponemos unos patos que nada, no hacen cual y se
van a enterar por la pantalla. Y los diseñadores utilizan técnicas
estándar de orientación a objetos. Aquí en el libro cada vez que se
habla de técnicas estándar de orientación a objetos quiero decir que el
diseño es una porquería. Porque justamente no han usado patrones de
diseño. Entonces la idea es que te van a pedir que añades nuevos tipos de
pato continuamente y eso. Y entonces el diseño inicial es este, tienes una
clase pato y todos los patos pueden nadar y hacer quack. La superclase se
encarga del código de la implementación, tenemos aquí un método quack,
un método nadar y un método mostrado y otros métodos patinas. El método
mostrado sí que es abstracto porque cada pato tiene un aspecto distinto,
pero el cual hay que nadar es igual para todos. ¿Veis? Aquí en las, esto
es la herencia, ¿no? Entonces los que heredan de pato, el pato real y el
pato pelirrojo, pues tienen sus métodos que lo muestran con el efecto
correcto, ¿no? Así que nada, la empresa viene sufriendo la presión de la
competencia y los directivos de la empresa han estado jugando al gol,
tienen una tormenta de ideas y necesitan algo realmente impresionante para
las juntas de accionistas en cada valor, ¿no? Entonces ahora... Han
pensado que los patos, además de nadar y hacer quack, pues tienen que
volar. Y han decidido que, bueno, pues nada, que eso lo va a los talentos
de pato y les ha dicho a los directivos que no hay problema porque son
programadores orientados a patos y que también no puede costar nada. Es
buenísimo. Y esto es lo que piensa el pato, dice, solo necesitan añadir
un método de volar en la clase pato y que todos los patos lo hereden. Es
hora de mostrar mi talento orientado a patos. Entonces, ¿qué es lo que
queremos? Entonces añadimos en la... En la clase, en la superclase
abstracta, añadimos un método de volar. Y ya está. Pues ese ha sido
básicamente el... Básicamente el trabajo. Y entonces algo ha salido muy
mal. A ver, voy a hacer un poco más de quichín. Pensa la directiva chunga
esta. Y después se hacen las juntas de accionistas. Hacen esto y nada más
y nada más. A partir de aquí vamos volando por la pantalla. Esto es una
broma, ¿qué pasa? Vete a mirar un poco LinkedIn. LinkedIn. Bueno, lo que
sea, una página para buscar el trabajo, ¿no? Lo que estaba diciendo. En
el libro poníamos un poco en algo así. ¿Qué ha pasado? Pues PASO no se
da cuenta de que no todas las subclases de pato deberían volar. Cuando
PASO ha añadido la nueva conducta a la superclase pato, también ha
añadido una conducta que no era adecuada para algunas subclases del pato.
Y ahora tiene objetos inanimados en el programa sin patitos. Es una
actualización localizada en el código y ha causado un efecto secundario
no local. Patito de goma voladoro. Entonces PASO dice que, bueno, que hay
un pequeño fallo, pero que podemos decir que es una característica y que
a él le mola. Y que lo que se hace pensar que era un gran uso de laiencia
para reutilizar código pues no ha salido tan bien respecto al
mantenimiento. Aquí el libro espero que haces que te... No es para que se
te quede el concepto en este libro, que lo repiten todas cinco veces, que
yo lo he revisado un poco porque es un poco gargante. Igual a los
americanos les funciona, pero a mí me pasó demasiado. Entonces, pues se
ha puesto a volar el pato real, el pato pelirrojo y también ha heredado
patito de goma. Entonces el patito de goma resulta que no tenía que volar.
Y de hecho los patitos de goma tampoco hacen cuac. Así que cuac lo hemos
sobre escrito para que haga mito. Por el momento me seguís y eso, ¿no?
Bueno, no ha salido la estrategia todavía, pero no os preocupéis que
luego sale. Entonces, claro, aquí lo que es esto que te ponen aquí, lo
que te están diciendo es que la herencia no es tan... La herencia como
para reutilizar el código, pues no funciona tan bien. Y ese es el tema,
que cuando uno estudia programación en chavos fetos al principio, pues
parece que la herencia es importante y lo es, pero no solamente lo es en el
sistema ese de que tienes un ejemplo de la clase base de personas y luego
tienes empleados, estudiantes y clientes y no sé qué. No es exactamente
así. Es un poco más complicado hacer que la herencia funcione bien, ¿no?
Aquí les importa más la composición que la herencia. Entonces aquí
está ese dedo que flexiona y dice siempre podría sobre escribir el
método volar en el patito de goma del mismo modo en que lo hago con el
método cuac. Entonces podemos sobre escribir volar para no hacer nada.
Dice, pero ¿qué va a pasar cuando añadamos patos señuelos al programa?
Se supone que estos no vuelan ni hacen cuac. Este es el pato señuelo, cat,
sobre el cilipa no hace nada, no hace nada el señuelo y volar, también
sobre el cilipa no hace nada. Esta es otra clase de la sororidad, al igual
que el patito de goma no vuela, pero además tampoco hace nada. Entonces,
aquí nos hacen una preguntilla, dice, ¿cuáles son, cuáles de las
siguientes opciones son desventajas de usar la herencia para proporcionar
la conducta de patos? Coge todas las aplicables, vamos a pensar. El código
se duplica a través de las subclases. ¿Qué os parece? ¿Pasaría eso o
no? Yo creo que eso no pasaría. ¿Qué? Que no debería de pasar, no se
duplica. No debería de pasar, pero está pasando porque se está
reescribiendo los métodos en las subclases para hacer las cosas. Entonces,
si cada vez que metes un pato nuevo tienes que empezar a personalizar que
si es que nada, que si es que vuela, que si es que no. Yo creo que sí
que... Todos, por ejemplo, todos los que no hacen nada, estás metiendo el
código de no hacer nada. Yo creo que sí que se duplica el código con
este diseño. No, se duplica, se triplica o lo que sea, ¿no? Que hay
conductas específicas que se repiten y que estás copiando tal cual en
todas las subclases. Los cambios de conducta en tiempo de ejecución son
difíciles, ¿cómo lo veis? O sea, si tú crees un pato de repente a medio
programa que no volaba, de repente se ponga a volar, eso va a ser difícil,
¿no? Con esta estructura. Ahora sí que sí, ¿no? Sí, ¿no? La C dice...
Sí, que habría que insertar más código. ¿Cómo? Que habría que
insertar más métodos para cambiar la conducta deseada, vamos. Sí, sí,
claro, pero si con este esquema parece que va a ser difícil. Es
complicado, si tienes una clase abstracta que tiene todos los métodos y
luego tú si acaso te pones a sobreseguir... ...pues parece que es
complicado. La C dice... No podemos hacer que los patos bailen. Bueno, esta
es la... La C trae una acción chorrada ahí en esto. La D dice... Es
difícil entender todas las conductas de los patos. Me parece. Bueno, se
supone que hay muchos patos, no solo los tres estos que nos han contado.
Ahora hay montones y montones. Pues claro, pues sí que va a ser difícil
porque habría que ir recorriendo la implementación de los patos uno por
uno para ver cómo sobreviven los métodos. Y la cosa es que muchas de esas
conductas van a ser comunes porque hay muchos que no vuelen o hay muchos
que hagan un quack de una forma específica y cosas así, ¿no? Pero la
verdad es que los patos no pueden volar y hacer quack al mismo tiempo.
Vale, pues... Pero los cambios pueden afectar de forma no intencionada a
otros patos. Eso parece que también, porque ya lo hemos visto, que
simplemente al añadir métodos ahí en la clase base pues nos ha
aprovechado. Porque ha habido cambios ahí no intencionados en los patos,
¿no? Así que bueno, parece que por ahí van los problemas. Pero bueno, ya
nos lo dice aquí que la herencia no es la respuesta. Pues eso se ha dado
cuenta de que probablemente la herencia no era la solución porque acaba de
recibir una circular que dice que los directivos quieren actualizar el
producto cada seis meses de manera que todavía no han decidido. O de
manera que todavía no han decidido. Eso se sabe que las especificaciones
seguirán cambiando y que no tendrá más remedio que mirar y tal vez
sobrevivir volar y quack para cada nueva subclase de pato para siempre. Por
tanto, necesita una forma más limpia de hacer que alguno, pero no todos,
los tipos de pato, vuelen a un quack. Está pensando aquí José. Y dice,
podría sacar volar fuera de la superclase pato y crear una interfaz
volador con un método de volar. De esa forma, solo los patos que se supone
que vuelan implementarán esa interfaz y tendrán un método de volar. Ya
que estamos, podría hacer una interfaz quack al mismo tiempo. Ya que no
todos los patos pueden hacer el quack. Y entonces este sería el diseño.
Como decía al inicio de la asignatura, que había que aprender UML, pues
nada, aquí estamos con el UML, ¿no? Estas son las clases y pato es una
clase y estas clases de abajo son subclases, ¿no? Tienen aquí la flecha
está sólida con la punta boca, que eso significa implementan. O sea, que
son, no, extienden. Y extienden a la... y luego por otro lado tenemos las
fechas con puntitos que son implementadas en la interfaz tenemos la
interfaz volador y la interfaz cuaqueador entonces por ejemplo el pato real
pues vuela y hace cuac la mayoría de los patos lo hacen pero el patito de
doma por ejemplo hace cuac pero como no vuela pues no implementa la
interfaz volador y el pato señuelo pues ni vuela ni hace cuac entonces
simplemente hereda de pato ¿Qué os parece la idea esta del diseño?
¿Cómo lo veis? ¿Este diseño soluciona los problemas o no? Parece más
limpio, ¿no? No sé Hombre, es más limpio menos desastroso que el de
antes pero pero no soluciona todos los problemas que nos han preguntado
antes porque en el fondo se sigue repitiendo código a chorros porque vale,
sí, hay un método de volar y un método de cuac y tú los tienes que
implementar y si no haces, si no vuelas pues no lo tienes que implementar
pero si vuelas de diferentes maneras y si haces cuac de diferentes maneras
y hay esas maneras digamos que se repiten bastante sí que estás
repitiendo código a chorros en los patos, ¿no? Entonces bueno, eso es lo
que pienso a la medida de leer el libro no tiene mucho mérito pero bueno
Pues tenemos aquí a la directiva chunga y esta es la idea es tonta que se
te pueda haber ocurrido ¿sabes lo que es el código duplicado? y pensabas
que tenías que sobreescribir unos pocos métodos, era malo ¿cómo te vas
a sentir cuando tengas que hacer un pequeño cambio en la interfaz volador
en las 48 subclases de pato? Pues ahí está ese es justo el problema que
hay que repetir el código por un tubo eso está mal y además es una
pesadilla de mantenimiento ¿qué harías tú si fueras José? pues sabemos
que no todas las subclases deberían tener conducta de vuelo o de hacer
cuac así que la herencia no es la respuesta pero mientras que el que las
subclases implementa en volador y o cuaqueador resuelve parte del problema
que no hay patitos de gama voladores destruye completamente la
reutilización de código para esas conductas así que crea una pesadilla
de mantenimiento diferente y por supuesto podría haber más de una
conducta de vuelo incluso entre los patos que sí vuelan Y que en este
punto podrías estar esperando a que venga un patrón de diseño en un
cabello blanco y te sacara del apuro. Pero qué gracia tendría eso, ¿no?
Vamos a buscar una solución al viejo estilo. Diciendo buenos principios de
diseño orientados a fotos. Y lo ves es tan inclusiva que quiere decir que
ni le tome a nadie. Que los buenos principios de diseño orientados a fotos
no valen. No resuelven todo. Y que bueno, como la anécdota no ha
funcionado muy bien, ya que la conducta de los patos sigue cambiando. Y no
es apropiado que todas las subclases tengan esa conducta. Las interfaces de
volador igual que ahora son algo prometedoras. Pero el problema es que las
interfaces dejadas no tienen implementación. Con lo cual no hay
reutilización de código, efectivamente. Eso significa que cada vez que
haya que modificar una conducta hay que perseguirla y cambiarla en todas
las subclases diferentes donde esa conducta está definida. Probablemente
introduciendo nuevos errores por el camino. Afortunadamente hay un
principio de diseño justo para esa situación. Los principios de diseño
lo están aquí con el yin y el yang. Y dice, identifica los aspectos de tu
aplicación que varían y separa los de los que se quedan iguales. Son
principios muy zen, totalmente. Es encapsular lo que varía. En otras
palabras, si hay algún aspecto de tu código que cambia, digamos con cada
nuevo requisito, entonces sabes que tienes una conducta que tiene que ser
sacada y separada de todo lo que no cambia. Eso quiere decir hacer una
nueva clase, normalmente. He aquí otra manera de pensar sobre esto. Este
principio. Una clase, o mejor dicho, una clase abstracta y luego subclases
de eso. Toma las partes que varían y encapsúlalas para poder alterar o
extender las partes que varían más adelante sin afectar a las que no. A
pesar de su simplicidad, este concepto forma la base de casi todos los
patrones de diseño. Todos los patrones proporcionan una manera de que una
parte de un sistema varíe independientemente de las otras partes. Es el
momento de sacar las conductas de los patos fuera de las clases pato.
Bueno, efectivamente, claro, este principio... Vamos a hablar de todos los
patrones porque este principio consiste en crear otra jerarquía de clases
distintas y meter un montón más de clases. O sea que así se puede
explicar casi todo el problema. A ver, vamos a ver. ¿Por dónde empezamos?
Bueno, aparte de los problemas con volar y cuar, la clase pato está
funcionando bien y no hay otras partes de ella que parezcan cambiar o
variar frecuentemente. Así que aparte de algunos pequeños cambios, la
clase pato la vamos a dejar tranquila. Ahora, para cambiar la clase pato,
vamos a hacer un cambio de la clase pato. ¿Preparar las partes? que
cambian de las que se quedan igual, vamos a crear dos conjuntos de clases
totalmente independientes de pato, una para volar y otra para quack. Cada
conjunto de clases contendrá todas las implementaciones de sus respectivas
conductas. Por ejemplo, podemos tener una clase que implementa hacer quack,
otra que implementa hacer niki y otra que implemente silencio. Pues nada,
aquí lo vamos a hacer. Aquí tenemos la clase pato, sigue siendo la
superclase de todos los patos. Y tenemos varias implementaciones de
conductas que van a vivir aquí. Por un lado vamos a tener las conductas de
vuelo y por otro lado vamos a tener las conductas de quack, que son
entonces las conductas del pato. Vamos a diseñar las conductas de los
patos. ¿Cómo vamos a implementar el conjunto de clases que van a
implementar las conductas de vuelo y quack? Pues para tener las cosas
flexibles, ya que la inflexibilidad fue lo que nos metió en líos en el
primer lugar, queremos asignar conductas a las instancias de patos. Por
ejemplo, podríamos crear instancias de un nuevo pato real y inicializarlo
con un tipo específico de conducta de vuelo. Y ya que estamos, ¿por qué
no asegurarnos de que podemos cambiar la conducta de un pato
dinámicamente? Deberíamos incluir métodos mutadores en la clase pato
para, por ejemplo, cambiar la conducta de vuelo de los patos reales en
tiempo de ejecución. Vale. Vamos a usar una interfaz para cada cosa.
Tenemos la interfaz conducta de vuelo, que la vamos a poner aquí. Habrá
una conducta de quack también. Cada implementación de una conducta
implementará cada una de esas interfaces. Así no serán las clases de
patos las que implementen las interfaces, sino otras clases independientes.
Tendremos un conjunto de clases que ya una única razón para existir será
representar una conducta. Por ejemplo, hacer nicking. Y es la clase de la
conducta, en vez de la clase de pato. Y implementará la interfaz de la
conducta. Por ejemplo, aquí vamos a tener las conductas de vuelo. Una es
volar con alas y otra no vuela. Entonces, bueno, cada pato va a utilizar
una conducta de estas. Vamos a ver cómo queda esto. A ver. Esta es una, ya
no es la directiva, es una desarrolladora chingada. Dice, no veo por qué
hay que usar una interfaz. Es para conducta de vuelo. Se puede hacer lo
mismo con una superclase abstracta. ¿No está ahí la gracia del
polimorfismo? No. Y bueno, me dijeron que programar para una interfaz, que
es otro de los principios, significa realmente programar para un supertipo.
Pues la palabra interfaz está sobrecargada, el concepto de interfaz y
luego la construcción interface dejada. Y luego las interfaces gráficas
también. Pero bueno, se puede programar para una interfaz sin usar un
interface. Es decir, se puede utilizar también en la clase abstracta y
sirve perfectamente. Vamos a explotar el polimorfismo programando para un
supertipo de forma que el objeto en tiempo de ejecución no esté bloqueado
en el código. Y podríamos parafrasar programa para un supertipo como el
tipo declarado de las variables debería ser un supertipo. Normalmente una
clase abstracta o una interfaz para que el código asignado a esas
variables pueda hacer de cualquier implementación concreta un supertipo.
Lo que significa que la clase que los declara no tiene por qué saber nada
acerca de los tipos específicos. Dice, bueno, para asegurarnos de que
estamos todos de acuerdo hay un ejemplo sencillo de un uso polimórfico.
Tenemos una clase abstracta animal que tiene dos implementaciones
concretas, perro y gato. Entonces, si tenemos esta implementación para
programar para una implementación, que es lo que no hay que hacer, aquí
tenemos perro d, new perro y hacemos d larga. Declarar la variable d de
tipo perro fuerza a nuestro código a usar una implementación concreta.
Estamos atándonos aquí. Pues malamente. En cambio, programar para una
interfaz o un supertipo sería animal, animal, new perro y luego animal
abstenido. Entonces, sabemos que es un perro, pero podemos utilizar la
referencia animal. Esto sería como un paso intermedio. Y mejor todavía
que cablear la instanciación del subtipo como new perro en el código,
vamos a asignar la inicialización concreta del objeto en tiempo de
ejecución. Entonces, este es el código. Bueno, a get animal. Y animal
abstenido. Con este cacho de código no sabemos cuál es el subtipo del
animal. Lo único que nos importa es que sabe cómo responder a abstenido.
Entonces, esto es muy importante. Este grado de abstracción, porque
normalmente vamos a estar haciendo el código y solo vamos a conocer la
superclase, el supertipo. Pero no sabemos realmente qué clase de verdad
es, de qué clase, de qué objeto hay en tiempo de ejecución aquí.
Entonces, aquí el animal tiene el método de abstenido. Y las
implementaciones concretas son el perro, que con el sonido es ladrar, y el
gato, que con el sonido es miar. Entonces aquí no sabemos con este código
si nos va a ladrar o nos va a hacer miar. Y eso es un poco lo que vamos a
hacer con los patos también. Una de las cosas que se hace es la conducta
de vuelo y la conducta de cuar. Y vamos a dar implementaciones concretas de
esas cosas. Por ejemplo, volar con alas no vuela. Y en el cuar, pues hacer
el cuar, hacer el ñiqui del patito de goma y también no hacer nada. En
este diseño, cada vez que tengamos una nueva clase de pato, la vamos a
asociar con alguna conducta de estas. En este diseño, otros tipos de
objetos pueden reutilizar nuestras conductas de vuelo y de cuar, porque
estas conductas ya no están extendidas dentro de nuestras clases pato. Y
podemos añadir nuevas conductas sin modificar ninguna de las conductas ya
existentes ni tocar ninguna de las clases de patos que usan conductas de
vuelo. Así conseguimos los beneficios de la reutilización sin el bagaje
que trae la herencia. Entonces, bueno, aquí tenemos una sección de
preguntas y respuestas. Y se pregunta, ¿siempre tengo que implementar mi
aplicación primero? ¿Ver dónde cambian las cosas y después volver y
parar y encapsular esas cosas? Pues no siempre. A menudo cuando estás
diseñando una aplicación, vas a anticipar qué áreas van a cambiar y
adelantarte construyendo. Y eso es la flexibilidad para tratar con ello en
el código. Verás que los principios y patrones se pueden aplicar en
cualquier etapa del ciclo de vida. Pregunta, ¿deberíamos hacer que pato
fuera una interfaz también? Respuesta, no en este caso. Como verás cuando
tengamos todo junto funcionando, el hecho de que pato sea una clase
concreta no es beneficia, ya que los patos concretos como el pato real y el
pato pelirrojo heredan propiedades y métodos comunes. Ahora que hemos
quitado lo que varía en la herencia de pato, tenemos los beneficios de
esta estructura. Sin los problemas. Otra pregunta, ¿parece un poco raro
tener una clase que solo es una conducta? ¿No se supone que las clases
representan cosas? ¿No se supone que las clases tienen tanto estado como
conducta? La respuesta es que en un sistema orientado a fotos sí, las
clases representan cosas que generalmente tienen tanto estado, variables de
instancia y métodos. Y en este caso la cosa resulta ser una conducta. Pero
incluso una conducta puede tener estado y métodos. Una conducta de abuelo
podría tener variables de instancia, Los atributos para la conducta de
vuelo, aleatorios por minuto, altitud y velocidad máximas, etc. Son
preguntas interesantes. Y ahora vamos a ver cómo se implementarán los
PATOS concretos. Entonces primero vamos a añadir dos variables de
instancia a la clase PATO que las vamos a llamar conducta de vuelo y
conducta de clave. Entonces aquí en el UML se permite poner en una clase,
tantos de la clase como estos, todo vuelo y todo clave, de este tipo. Y
luego abajo ponemos los métodos. No siempre nos interesa ponerlo pero
cuando queremos hacerlo explícito lo podemos hacer. Entonces las variables
de conducta están declaradas del tipo de la importancia de la conducta. Y
esto lo quedan ya todos los... Y las variables de instancia que contienen
una referencia a una conducta específica en tiempo de ejecución. Entonces
por ejemplo, addQuack, que es uno de los métodos. Interesante si lo echas
a volar. Entonces addQuack lo que va a hacer, va a ser llamar a la conducta
de CLAP, a la variable de instancia de conducta de CLAP para que haga CLAP.
O sea, es como... Hemos hecho delegación, hemos delegado en el objeto
cdQuack que haga el QUACK. Eso lo de la delegación es cuando tenemos un
método que tenemos simplemente una llamada a otro método. Sencillo, ¿no?
Para hacer QUACK un PATO simplemente permite que el objeto que es
referenciado por el cdQuack haga QUACK por él. En esta parte del código
no nos importa qué tipo de objeto es porque aquí no sabemos qué conducta
de QUACK es, nos da igual. Lo único que nos importa es que sabe cómo
hacer el QUACK. Y bueno, como todo esto... Esto era muy abstracto, pero se
ha llegado el momento de ver cómo asignamos las variables de distancia de
vuelo y cdQuack. Vamos a ver la clase PATO real que hereda de la clase
PATO. Entonces en el constructor cdQuack hacemos un new QUACK y en cdVuelo
hacemos un new VuelaCanalas. Entonces un PATO real utiliza la clase QUACK
para manejar sus QUACKs. Así que cuando se llame a QUACK la
responsabilidad del QUACK se delega al objeto cdQuack, que es el que tiene
QUACK. Y eso nos da un QUACK. Y VuelaCanalas es como su conducta de vuelo.
las variables y mostrar un pato real auténtico hemos hecho una
reestructura del método nuestro por tanto el pato real es un pato de
verdad que hace quack no ñiqui ni es un pato nudo lo que pasa es que
cuando se instancia un pato real el constructor inicializa la variable de
instancia heredada a hacer quack a una nueva instancia de tipo quack una
implementación concreta de conducta de quack y lo mismo pasa con la
conducta de vuelo el constructor de pato real inicializa la variable de
instancia a hacer vuelo con instancia de la clase vuela con alas una
implementación concreta de conducta de vuelo ahora pues hemos solucionado
muchos problemas porque seguramente habrá muchos patos que hagan quack la
mayoría y entonces no tenemos que repetir el código de quack en todas
esas clases sino que simplemente vamos a hacer un objeto de la clase quack
que es el código de quack que es la clase quack que era la que
implementaba la conducta de quack de manera que es muy sencillo asignar una
conducta y si tenemos que hacer cambios en quack solo tenemos que hacerlos
en un sitio el código es partido y parado por todas las clases el diseño
es muchísimo mejor entonces pues bueno aquí la clase de pato es así la
clase de extractor y también tenemos otra la conducta de vuelo en esta
interfaz y vuela con alas simplemente imprime el código de vuelo estoy
volando la clase no vuela porque el método de volar simplemente imprime el
código de volar la clase quack imprime el método de quack el quack mudo
imprime silencio y el quack niki imprime niki entonces por ejemplo aquí
tenemos esto siempre lo hace en el libro este que tenemos una clase de
texto entonces la clase simpático es esta en main hacemos aquí un test
hacemos un nuevo pato real y le damos a haz quack y haz volar y lo
ejecutamos y nos sale pues lo que hace el pato real que hace quack de
verdad y volar pues nos dice que estoy volando con lo cual pues nada el
test parece que ha sido exitoso ¿cuántas cosas que se pueden hacer con
esto? pues como tenemos este diseño tan bueno podemos eh asignar conducta
dinámicamente. Es decir, ¿qué vergüenza sería tener todo este talento
dinámico en nuestros patos si no usarlos? Supongo que quieres determinar
la conducta del pato a través de un método mutador de la subclase de
pato, en vez de instanciarla en el constructor del pato. Entonces añadimos
nuevos métodos a la clase de pato, que son setConductaDeVuelo, y la
setConductaDeQuad, pues la metemos aquí. Entonces podemos usar estos
métodos en cualquier momento para cambiar la conducta del pato al vuelo.
Pues podemos hacer un nuevo tipo de pato, pato modelo. Y en el constructor
decimos que no vuela y no hace cuarto. Comienza a subir a mi suelo sin
forma de volar. Muestra que es un pato modelo. Y luego hacemos un nuevo
tipo de conducta de vuelo, que es vuela con cohete, que implementa la
conducta de vuelo. Y en su método de volar decimos vuelo con un cohete. Y
hemos cambiado la clase de prueba para añadir el pato modelo y hacer que
el pato modelo vuele con un cohete. Entonces tenemos lo que antes era el
pato real, que hacía todo aquí volado. Y aquí nos ha añadido un pato
modelo, un nuevo pato modelo, lo hacemos volar. Luego le cambiamos la
conducta de vuelo para que vuele con un cohete, un nuevo vuelo con un
cohete, y lo hacemos volar otra vez. Entonces, primero esto era el pato
real, que hacía todo aquí estoy volando. Después tenemos el pato modelo,
que dice no puedo volar. Y finalmente, como lo hemos puesto la conducta de
vuelo con un cohete, dice vuelo con un cohete. Es decir, que ahora estamos
haciendo, estamos utilizando composición con las conductas de vuelo y las
conductas de quack, en vez de estar utilizando simplemente herencia de la
clase base pato, que era lo que hacíamos al principio. La composición es
mucho más flexible, porque la estructura de herencia es completamente
rígida. Uno hereda de lo que hereda y ya está. Pero la de composición no
es tan rígida, porque me puedo olvidar de la primera conducta de vuelo que
tenía y asignar otra nueva conducta de vuelo en tiempo de ejecución. Por
eso la composición, digamos, que da mucho juego dinámicamente. Entonces,
hemos visto este ejemplo de los patos, pero el... El concepto, digamos, que
se puede generalizar ahí a siempre que hay unas conductas... encapsuladas.
Entonces, si miramos con perspectiva, podemos mirar un diagrama de clases
aéreo estructurado que sería esto de aquí. El pato que tiene la conducta
de vuelo, fe de vuelo y fe de quark, los métodos que teníamos antes,
incluyendo el sexto conducta de vuelo y el sexto conducta de quark.
Tenemos, por ejemplo, el pato real, el pato peligroso, el pato goma, el
pato señuelo. Conductas de vuelo, tenemos la interfaz y luego, por
ejemplo, que la canala si no vuela y la conducta de quark. Suplementaciones
concretas son el quark knitting y el quark muller. Entonces, estas
conductas realmente son algoritmos y son intercambiables. Podemos pensar en
cada conjunto de conductas como un conjunto de algoritmos. Observa también
que hemos empezado a describir las cosas que fueron un poco diferentes. En
vez de pensar en las conductas de los patos como un conjunto de conductas,
vamos a empezar a pensar en ellas como una familia de algoritmos. En
diseños simpáticos, los algoritmos representan cosas que un pato haría.
Pero podríamos haber usado igualmente las mismas técnicas para un
conjunto de clases que implementaran las formas de calcular los impuestos
según cada comunidad autónoma. Entonces, hay que prestar atención a las
relaciones entre clases y tenemos las relaciones es un, tiene un e
implementa. Tenemos tres tipos de relaciones aquí como se pueden ver en
las rayitas estas. Tenemos tres tipos de flechas. Entonces, el tiene un
puede ser mejor que es un. La relación tiene un es interesante. Cada pato
tiene una conducta de vuelo y una conducta de quark en las que delega a
volar y hacer quark. Cuando usas dos clases juntas así estás usando
composición. En lugar de heredar su conducta, los patos consiguen su
conducta por composición con un objeto de conducta. Esto es una técnica
importante. De hecho, hemos estado usando nuestro tercer principio de
diseño. Que es favorece a la composición sobre la herencia. Vamos, más
claro no se puede decir. Como hemos visto crear sistemas usando solo
composición te da mucha más flexibilidad. No solo puedes encapsular una
familia de algoritmos dentro de su propio conjunto de clases sino que
también te deja cambiar la conducta en tiempo de ejecución. Siempre y
cuando el objeto que estés componiendo implemente la interfaz de conducta
correcta. La composición se usa en muchos patrones de diseño y verás
más cosas acerca de sus ventajas y desventajas más adelante. Entonces
tenemos aquí a la gurú enrollada de la orientación a objetos que habla
con su estudiante. Y el maestro dice, saltamontes, dime qué has aprendido
sobre el camino orientado a objetos. El estudiante dice, maestro, he
aprendido que la promesa del camino orientado a objetos es la
reutilización. Continúa saltamontes, maestro, a través de la herencia
todas las cosas buenas pueden ser reutilizadas. Y recortaremos el tiempo de
desarrollo tal y como cortamos raudamente el bambú en los bosques.
Saltamontes, te pido más tiempo en el código antes o después de que se
haya completado el desarrollo. Y el estudiante, la respuesta es después,
maestro. Siempre perdemos más tiempo manteniendo y cambiando el software
que en su desarrollo inicial. Pues sí, esto es ingeniería de software
básica. Dice el maestro, entonces, saltamontes, ¿deberíamos poner el
esfuerzo en la reutilización antes que en el mantenimiento y en la
extensibilidad? Maestro, creo que hay verdad en esto. Pues claramente está
equivocado, ¿no? Dice el maestro, digo que todavía tienes mucho que
aprender. Quiero que vayas a meditar un poco más acerca de la herencia.
Como has visto, la herencia tiene sus problemas y hay otras formas de
lograr la reutilización. Y aquí tenemos el poder mental. Dice, un
llamador de patos es un dispositivo que usan los cazadores para imitar las
llamadas quacks de los patos. ¿Cómo implementarías tu propio llamador
que no herede de la clase pato? Bueno, aquí lo que nos están diciendo es
que claro, una vez que tenemos implementadas las cosas podemos salir del
esquema más o menos rígido que teníamos, ¿no? Entonces ahora podríamos
hacer una clase que imitara a los patos pero que no fuera un pato, ¿no? Un
silbato de patos o algo así, ¿no? Y eso podría aprovechar las clases de
hacer quacks, ¿no? Sin necesidad de crear patos. Es decir, que una cosa
que hemos creado con un objetivo, luego la podemos reutilizar con otros
objetivos que han aparecido después, ¿no? Entonces, nada, hablando de
patrones de diseño, nos dan aquí las felicidades por nuestro primer
patrón. Acabas de aplicar tu primer patrón de diseño, el patrón
strategy, eso es. Vamos a utilizar el patrón Strategy para pulir las
aplicaciones simpáticas. Gracias a este patrón, el simulador está listo
para cualquier cambio que puedan tramar esos directivos en su próximo
viaje de negocios a la manga. Como hemos tomado efecto de ruido para
aplicarlo, aquí está la descripción formal de este patrón. Es que el
patrón Strategy define una familia de algoritmos, los encapsula y los hace
intercambiables. Strategy permite que el algoritmo varíe
independientemente de los clientes que los usan. Por ejemplo, como en el
ejemplo que decía que esto se podía aplicar para los impuestos en una
comunidad autónoma, pues bueno, si te cambias de comunidad autónoma, pues
igual puedes cambiar a tu estatus fiscal o algo de eso. Me voy a dar la
flexibilidad que se consigue con estas cosas. Entonces, los patrones de
diseño tienen varios componentes. Tienen un nombre y tienen unas
características. Y entonces, la utilidad, aparte de programar muy bien, es
que te permite comunicarte mejor. Porque cuando te comunicas usando
patrones, estás haciendo más que solo compartir cerca. Estos vocabularios
compartidos son poderosos. Cuando te comunicas con otro desarrollador de tu
equipo usando patrones, no estás comunicando el nombre de un patrón, sino
todo un conjunto de cualidades, características y restricciones que el
patrón representa. Entonces, los patrones te permiten decir más con
menos. Gracias. El nivel de patrones te permite estar en el diseño durante
más tiempo. En vez de descender al nivel de la implementación de los
aspectos y las clases con pelos y señales. Y finalmente, los vocabularios
compartidos animan a más desarrolladores junior a ponerse al día. Bueno,
eso había hace mil años cuando estuve en el libro este. Dice, ¿cómo uso
los patrones de diseño? Pues todos hemos usado librerías y frameworks ya
desarrollados. Nos cogemos y escribimos algo de código. Contamos rápido.
Lo compilamos y nos beneficiamos de un montón de código que alguien ha
escrito. Usa en la API de Java de toda la funcionalidad que te da Red,
Vuey, Yo, etc. Las librerías y frameworks ayudan mucho en un modelo de
desarrollo en el cual puedes coger y elegir componentes e enchufarlos. Pero
no te ayudan a estructurar tu propia aplicación de manera que sea más
fácil de entender, más mantenible y más flexible. Ahí es donde entran
los patrones de diseño. Los patrones de diseño no entran directamente en
tu código. Primero entran en tu cerebro. Una vez que hayas cargado tu
cerebro con un buen conocimiento práctico de patrones, puedes empezar a
aplicarlos en tus nuevos diseños. Y moldear tu código añejo cuando veas
que se está degradando en una jungla inflexible de códigos parejos. Un
puñado de patrones que pasan a tu cerebro y luego tu código ahora es
mucho mejor. Es decir, no se trata de que los patrones estén implementados
y tú digas, oh, cojo la implementación y ya hago unas llamadas ahí a una
app y ya está todo el trabajo hecho. No. Los patrones te ayudan a
diseñar. Exactamente. Por eso la asignatura es de diseño de aplicaciones
orientadas a objetos. Vamos a ver las preguntas y respuestas de esto. Si
los patrones son tan guays, ¿por qué no hay una librería de
implementaciones para que no tenga que hacerla yo? La respuesta es, los
patrones de diseño están a nivel superior que las librerías. Los
patrones de diseño nos dicen cómo estructurar clases y objetos para
resolver ciertos problemas. Y es trabajo nuestro adaptar esos diseños para
que se ajusten a nuestra aplicación particular. Eso es justamente lo que
tenéis en la práctica, porque preguntan, ¿es conveniente utilizar aquí
el patrón no sé qué? Pues, hala, adáptalo a la estructura del problema
y tal y que cual. Preguntan, ¿no son las librerías y los frameworks
también patrones de diseño? No, las librerías y los frameworks no son
patrones de diseño, pero pertenecen a implementaciones específicas que
linkamos con nuestro código. A veces, sin embargo. Los frameworks hacen
uso de patrones en sus implementaciones. Eso es genial, porque una vez que
entiendes los patrones, aprenderás más rápido las APIs estructuradas
según patrones de diseño. Pregunta, entonces, ¿no hay librerías de
patrones de diseño? No, pero encontrarás catálogos de patrones con
listas de patrones que puedes aplicar en tus aplicaciones. Me gustan mucho
las preguntas estas, porque está claro que los autores han dado curso de
esto y están estudiando las preguntas que les hace la gente. A ver, ¿por
qué? ¿Por qué no hay patrones de diseño? La desarrolladora escéptica
dice, los patrones no son más que principios de diseño orientados a
objetos. Y la gurú de los patrones enrollada dice, un error común,
exactamente. Pero la cosa es más sutil, te queda mucho que aprender. Y
aquí va un diálogo y dice, la desarrolladora dice, vale, pero ¿no es
esto simplemente buen diseño orientado a objetos? Quiero decir, siempre y
cuando siga la encapsulación, sepa de abstracción, herencia. Y
polimedicismo, ¿realmente necesito pensar sobre patrones de diseño? ¿No?
¿No es algo muy inmediato? ¿No han hecho todos esos cursos de
orientación a objetos para esto? Creo que los patrones de diseño son
útiles para gente que no sabe diseño orientado a objetos. ¡Ah! Este es
uno de los verdaderos malentendidos del desarrollo orientado a objetos, que
por conocer lo básico de la orientación a objetos se nos va a dar bien
construir sistemas flexibles, reutilizables y mantenibles. Eh, ¿no? No. Y
resulta que construir sistemas orientados a objetos con esas propiedades no
siempre es obvio y solo se ha descubierto cómo hacerlo con mucho trabajo
duro. Creo que empiezo a entenderlo. Estas formas, a veces no inmediatas,
de construir sistemas orientados a objetos se han sistematizado. ¡Sí! En
un conjunto de patrones llamados patrones de diseño. Entonces, si sé
patrones, ¿puedo saltarme el trabajo duro y saltar directamente a diseños
que siempre funcionan? ¡Sí! Hasta cierto punto. Pero recuerda, el diseño
es un arte. Siempre habrá un toma y taca. Pero si sigues unos patrones de
diseño bien pensados y de eficiencia aprobada, tendrás mucha ventaja. ¿Y
qué pasa si no encuentro un patrón? Recuerda que hay unos principios de
orientación a objetos que subyacen a los patrones y conocerlos te ayudará
a enfrentarte al problema si no encuentras un patrón que se ajuste a él.
Principios. Subo y filastración, encapsulación y... y vencia, supongo.
Así, uno de los secretos para crear sistemas orientados a objetos
mantenibles consiste en pensar en cómo podrían cambiar en el futuro y
estos principios enfocan estos asuntos. Y recuerda, conocer conceptos como
abstracción, herencia y polimorfismo no te convierte en un buen diseñador
orientado a objetos. Un gurú del diseño piensa en cómo crear diseños
flexibles, fáciles de mantener y susceptibles de cambiar. Pues
efectivamente, solo para haber estudiado programación orientada a objetos,
si lees el libro no te convierte en un grandísimo diseñador orientado a
objetos, para nada. Vale, y este sería el chapitulillo este de strategy.
¿Qué os ha parecido la introducción a un patrón de diseño? Vale, tío
mío, la verdad es que estoy muy perdido. Hombre, como introducción pues
igual, vale. Tendría que verlo muchas más veces para poder asimilar algo.
Es súper abstracto esto. Es abstracto a nivel ahí máximo. Sí, sí.
Tienes razón. Claro, sí, sí. Por eso lo explican todas tantas veces y
vienen los ejemplos y todo eso. Porque hay que trabajar en un nivel de
abstracción bastante alto, la verdad. La verdad que sí. El libro este de
Concepts, Design, Patterns es muy famoso y tiene muy buenas críticas. Y
las únicas críticas gordas que le hacen pues es que como que anima mucho
a la gente a empezar a aplicar objetos a mensalva, o sea, patrones. Y una
de las preguntas proviene ya como al final del libro en la página 600 o no
sé qué. Dicen ¿y si estoy haciendo una aplicación y he aplicado
patrones para que me den más flexibilidad y no sé qué? Pero luego
finalmente me doy cuenta de que no necesito tanta flexibilidad que hago por
borrar los patrones. Entonces, claro, la crítica que le hacen es que se
han expuesto a la página 600 para decir eso cuando lo que no se debe hacer
es lo que llaman aquí la fiebre de los patrones, de empezar a aplicar
patrones para aplicarlos porque la solución no siempre es un patrón.
Patrones no son una cosa mágica que te solucione todos los problemas. Y a
veces si eliges el patrón se ha equivocado o un patrón que no pinta nada
pues eso es un problema. Eso hay una cosa además de los patrones que se
llaman antipatrones y hay un antipatrón que es el golden summer es el
martillo de oro ese que es como el refrán ese que dice que al que tiene un
martillo te le parquen clavos que cuando aprendes un patrón lo quieres
utilizar ahí todas las situaciones que a lo mejor no siempre es la mejor
idea. Pues hasta que no tienes ahí una idea clara de todos los patrones
normales es mejor tomárselo con calma no empezar a aplicar patrones a
distro y siniestro. Pero bueno. Los patrones estos los introdujeron en el
libro este de y sus colegas en el 94 y tuvieron muchísimo éxito ¿no?
Entonces en el libro ese y aquí me parece no sé si son 23 patrones creo
que es lo que hay y son los famosos techos hay varios que son una
porquería y realmente no se inventan nada pero como el libro es muy
influyente pues ahí se han quedado, nadie ha tenido el valor de quitarlos
del medio, lo que sí ha pasado es que se ha producido como una una fiebre
de los patrones esto fue hace hace 30 años y entonces se han identificado
como patrones estos patrones son como muy generales luego hay patrones como
para cosas específicas y hay vamos pero muchísimo, fácilmente te puedes
hacer una lista de 400 patrones para luego para cosas más concretas yo he
hecho un montón de trabajo de fin de grado y eso y la gente cuando hace
aplicaciones y no sé qué empieza ahí con el patrón esto, el patrón, lo
otro y al final es ahí madre mía los importantes son estos pero que luego
en cada jerga y en cada cosa meten un montón de patrones ¿qué te ha
parecido Lourdes? nada, a nadie por lo menos ha sido a ver no esa menos la
lectura del libro parece bueno, por lo menos un poco más entretenida que
los típicos pero sí es verdad que es bastante abstracta si no le pones un
print el F de cualquier cosa que relacione el método con lo que está
haciendo no no se sale vamos pero nosotros nos conocemos ¿no? pues yo creo
que sí sí ¿no? que estuviste de becaria o algo de eso, con lo de
psicología sí, sí hace unos veinte años hace muchos años sí, sí, sí
que sigues aquí en el tema este ¿no? pues he retomado este año he vuelto
a retomar este año así que para sacarlo ya del todo pero uff cuesta,
cuesta ¿eh? ¿empezaste hace mucho o qué? ¿cómo? ¿empezaste hace mucho
o qué? sí, sí o sea, a ver he empezado he vuelto a hacer cosas he vuelto
a empezar otra vez este este año, lo que pasa es que lo había dejado
aparcado ahí la carrera y este año he dicho venga, ya, a por todas vamos
es un clásico de los estudiantes de la UNED, que se lo dejan ahí 10 años
y luego vuelven o lo que sea pues mira, 17 años 18 prácticamente madre
mía me pasa el tiempo, me estoy sintiendo viejo sí, sí, sí venga vamos
a ello sí, sí, porque es que estaba viendo el nombre en la pantalla y
digo, coño, yo este nombre lo conozco por la voz al principio no te había
reconocido pero la voz estaba muy callada, pero cuando he visto el nombre
sí, sí yo sé que veo ristras ahí de lista de nombres a porrillo, pero
bueno bienvenida de vuelta muchas gracias pues, lo del libro este pues va
así vamos, hay como un más o menos un capítulo para cada para cada
patrón interesante los que son un churro se los pasa todo de golpe porque
no, o sea te lo dedicas solo una página o dos páginas a cada patrón y a
los interesantes, digamos, importantes a esto le dedican más tiempo y eso
el modelo de vista controlador pues es una vez que al final porque es que
realmente utiliza un montón de patrones de estos antes por ejemplo este
era el observer ese cuando tenemos que dar un corcillo de hora si queréis
podemos empezar con esto no nos va a dar tiempo, pero bueno, para
introducir un poco la cosa perfecto vale, pues nada, no he tenido las
felicidades, que te quito ganar la licitación para construir las
estaciones meteorológicas con conexión a internet de última generación
de temporama INC entonces nos manda una carta a diseñar esto desde el
callejón del Tornado dice bla, bla, bla bueno, la carta sabe un poco el
rollo y dice la estación meteorológica se basará en nuestro objeto
datos-tiempo pendiente de patente que lleva a la cuenta de las condiciones
meteorológicas actuales temperatura, humedad y presión atmosférica
Queremos que crees una aplicación que inicialmente proporcione tres
pantallas de visualización, una del tiempo activado, la otra de
estadísticas y una previsión sencilla. Todo ello actualizado en tiempo
real a medida que el objeto de otro tiempo recibe las mediciones
actualizadas. Y además es una estación que se puede expandir. Temporama
quiere publicar una API de forma que otros desarrolladores puedan escribir
sus propias pantallas de visualización y enchufarlas directamente.
Queremos que tu proporción indique API. Api, claramente esto es antiguo
porque hoy en día habrían hecho la tienda de aplicaciones de estaciones
de teorelógica. Temporama piensa que tenemos un gran modelo de negocio.
Una vez que los usuarios se enganchen, pretendemos cobrarles por cada
pantalla que usen. Y ahora viene lo mejor, que pagaremos con acciones de la
empresa. Estamos deseando ver tu diseño y aplicación al país. Este es el
panito huracán que tiene Startup Team. Entonces bueno, el libro este es un
poco básico como ya pronuncié. Es un poco cercano porque siempre mete
aquí puyas de planes de negocio absurdos y gente que tiene mucho humor en
el que pagarse con dinero que paga con acciones y esas cosas. Que se ve que
lo han vivido en sus propias carnes porque esto no se puede improvisar, eso
me lo ha dicho. Vamos a ver la aplicación de monitorización esta. Tenemos
los actores estos que son el dispositivo físico que adquiere los datos.
Que nos da igual. Nosotros con el hardware no vamos a hacer nada. Que tiene
un sensor de humedad, un sensor de temperatura y un sensor de presión
atmosférica que es un plan me alegro. Pero que sale aquí a la izquierda
es estupendo y nos da un poco igual. Luego tenemos la clase datos-tiempo
que va a tener una foto de esa clase solo. Que extrae los datos y aquí
están los visores. Que hay tres pero bueno, aquí hemos puesto uno de
ellos que es el de tiempo actual. Que va a hacer la temperatura, la humedad
y la presión y ya está. No nos vamos a complicar esto efectivamente. Lo
de la izquierda me lo da la empresa Timporame y lo de la derecha pues lo
implementamos nosotros. Entonces el J-Datos-Tiempo es que sabe cómo va con
el hardware y nuestro trabajo es crear una app que utiliza los
J-Datos-Tiempo para actualizar los tres visores. Pues vamos a desempaquetar
la clase de datos-tiempo. Como había prometido a la mañana siguiente los
ficheros fuentes de la clase de datos-tiempo. Ya han llegado, se
sobreentiende el anuncio de... Y fechando un ojo al código las cosas
parecen bastante intuitivas. Tenemos aquí la descripción de la clase,
está a tiempo datos, tiene unos métodos de acceso, qué temperatura, qué
timidez, qué expresión. Estos tres métodos devuelven las medidas más
recientes. No nos importa cómo se afinalizan variables, en efecto a tiempo
datos sabe cómo conseguir datos actualizados. Y luego está el cambio de
medidas. Cada vez que se actualizan las medidas se llama este método.
Entonces, public, cambio de medidas, tu código aquí. Para desarrollar un
objeto hay que dejar una pista sobre qué hay que implementar. Hay que
implementar esto, básicamente. Entonces, ¿por qué hacen esto? Porque a
veces eso hace que haya muchas mediciones por segundo o lo que sea y si no
ha cambiado mucho la cosa, pues no es necesario cambiar el visual. Por eso
el cambio de medidas este se llama cuando realmente hay un cambio
importante. Eso es, nuestro trabajo consiste en implementar cambios de
medidas para que se actualicen las tres pantallas, vamos a verlo. ¿Qué
sabemos hasta ahora? Pues las especificaciones no están tan claras, pero
tenemos que acompañárnoslas, así que es lo que sabemos hasta ahora. La
clase de tiempo datos tiene métodos selectores, o sea, de acceso,
temperatura, temperatura y la presión, que están aquí. Ahora que hay
nuevas medidas disponibles se llama el método de cambio de medidas. No
sabemos cómo se llama este método ni nos importa, solo sabemos que se le
llama y punto. Vamos a implementar tres elementos de visualización que
usan los datos meteorológicos. Estas pantallas se tienen que actualizar
cada vez que el tiempo de datos tenga medidas nuevas. Este es el visor 1,
este es el 2, son las estadísticas que van a medias, una mínima y una
máxima y la predicción. Bueno, nosotros esto en realidad no nos va a dar
igual. Y luego, el sistema debe ser extensible y hay un visor aquí del
futuro que se supone que se puede usar, ¿no? Pues vamos a ver ahí un
primer intento de cómo enfocar aquí, ¿no? Ahí lo de la estación
meteorológica, seguimos la pista que nos dio el timporama y entonces la
clase de tiempo datos, esto, datos-tiempo, a ver, me parece que lo he
cambiado de nombre, pero bueno. Yo creo que se entiende. Hacemos el cambio
de medidas y entonces metemos la temperatura, la humedad, la presión en
unos float que son pues los numerillos en tomas flotantes, pero los que
ocupan poco, ¿no? Porque los otros son... Y dice aquí, pide las medicinas
más recientes llamándole los métodos de acceso del paciente. Todo eso ya
está implementado. Y ahora tenemos que actualizar los propios visores que
hay. El visor de condiciones actuales, el visor de estadísticas y el visor
de predicción. Ahora se actualiza por la temperatura, la humedad y la
presión. No habrá otras cosas aquí, se me ha quedado esto en inglés
ahí en el libro original. Entonces, vale, ya nos hacen unas preguntillas
ahí para que vayamos pensando sobre el diseño. Y se señala todas las
opciones ciertas. Dice, ah, estamos implementando para implementaciones
concretas, no interfaces. ¿Qué os parece a vosotros? Esta cosa que
tenemos aquí. ¿Son programados para interfaces o para implementaciones?
Yo creo que son una implementación concreta. ¿Pero para una
implementación? Una implementación concreta, porque aquí no se ven
interfaces por ningún lado, vamos. Ni una. Para cada nuevo visor
necesitamos alterar el código, ¿qué os parece? Sí, hay que añadir un
nuevo visor. Claro, tendríamos que, digamos, abrir otra vez la clase esta
y aquí meter otra línea debajo de esto del nuevo visor para que actualice
y no sé qué. Cada vez que haya un visor nuevo, pues vamos a tener que
cambiar el código de la clase. F. No tenemos manuales. ¿Hay manera de
añadir ni quitar visores en tiempo de ejecución? ¿Eso es cierto o no?
Sí, porque son los que son. Son los que son, efectivamente. Aquí no hay
nada para añadir ni para quitar, además. Lo más doloroso es que añadir
y desañadir líneas y quitarlos es quitar líneas. O sea, que no hay
manera. Dice, los diferentes visores no implementan una interfaz común.
Vamos. Es más pillado. Y tú, Juan Carlos, tú. ¿Qué piensas? No me has
dicho nada. No, no. Estoy perdido. Directamente. hace mucho que estudié
esto y no estoy vamos, estoy ahora mismo reencontrándome o sea que
estudié Java, digo hace mucho ¿no la hiciste el año pasado? no, ¿qué
va? no, hace mucho, me la han convalidado me la han convalidado hace mucho
y bueno, pues me estoy reencontrando otra vez con esto me pasaba un poco lo
mismo que a la compañera ya, ya, ya hombre, sí, entonces es más falo,
sí, si el Java lo tiene más oxidado estoy empezando también a mirar la
asignatura esta de programación orientada a objetos otra vez y bueno, pues
nada, a refrescar conceptos y claro, hay muchas cosas que dices que no me
suenan pero bueno dímelo, dímelo si solo estáis dos bueno, nada,
tranquilo yo observo observo y bueno pues me iré quedando a mí me da
igual que me interrumpáis si esto es para que aprendáis vosotros gracias
no sé no sé decirte tienes una duda muy grande, ¿no? sí, enorme yo soy
todo una duda bueno, bueno, espero que te vaya poniendo al día hombre sí,
no me queda otra aquí lo que dice los diferentes visores no implementan la
interfaz común pues vamos a ver pues la respuesta sería pues sí y no o
sea, no porque no hay una interfaz de visor con unos métodos y un no sé
qué pero realmente se podría hacer porque si os fijáis, los tres visores
llaman a un método actualiza es decir, que el método se llama igual en
los tres lados y les pasa la temperatura, la humedad y la presión en todas
las cosas o sea, se podría crear una interfaz de visor que tuviera un
método actualiza que tomara como parámetro la temperatura, la humedad y
la presión y así por lo menos sí que habría una interfaz común, ¿no?
o sea que la D sería pues un poco sí, un poco no la E, dice no hemos
encapsulado lo que varía ¿qué pensáis? a ver, encapsulado no está
porque lo que varía realmente son los visores Aquí no se ha encapsulado
nada de nada. Claro, o sea, realmente no está encapsulado. Eso lo va a
hacer justo después, porque va a decir que todo este proceso de aquí hay
que encapsularlo en otra cosa, justamente. Dice, estamos violando la
encapsulación de la clase de atestimiento. ¿De la clase? ¿Qué ha dicho?
Atestimiento, nuestra clase, que estamos violando su encapsulación. Pues,
no sé. Bueno, en cierto modo sí, porque estamos, se supone que vamos a
estar abriendo la clase para añadirle líneas o quitarle líneas aquí
cada vez que queramos cambiar los visores. Así que, en ese sentido, la
estamos violando un poco, por lo visto, la encapsulación, no la clase. A
ver, ¿qué falla en nuestra implementación? Vamos a pensar en todos esos
conceptos y principios orientados a las fotos. Es que, a vosotros os
parecerá, igual os parece una frase inocente, pero yo que me he leído el
libro un montón de veces, veo ahí la mala leche que me meten aquí a TV.
En fin. Vamos a ver, este era el dato de tiempo que tenía el que es
temperatura acumulada. Entonces, veis, aquí este otro saco. Y esta es la
zona de cambio. Esto es lo que tenemos que encapsular, esto de los visores.
Dice, al codificar para implementaciones concretas, no tenemos manera de
añadir o quitar visores sin hacer cambios en el programa. O sea, que por
ahí van algunos de los tiros. Pues, al menos parece que usamos una
interfaz común para hablar con los visores. Todos tienen un método de
actualiza que usa los valores de temperatura, humedad y presión. Tenemos
aquí un nuevo, recién llegada en la empresa. Y ya sé que yo soy nuevo
aquí, pero ya que estamos en el capítulo del Patrón Observer, quizás no
deberíamos empezar a usarlo. Vamos a echar un vistazo a Observer y
después volveremos y pensaremos cómo aplicarlo a la aplicación de
monitorización metodológica. Dice, te presento al Patrón Observer. Dice,
¿ya sabes cómo funciona? Las suscripciones a periódicos y revistas. Un
editor de periódicos abre el negocio y empieza a publicar periódicos. Te
suscribes a un editor concreto y cada vez que hay una nueva edición, te la
mandan. Mientras sigas suscrito, te llegan nuevos periódicos. Pero
suscribes cuando ya no quieres más periódicos y dejan de enviártelos. Y
mientras el editor siga en activo, la gente de los hoteles, líneas aéreas
y otros negocios se suscriben y desuscriben constantemente del periódico.
Los editores más suscriptores igual a patrón observer. Si entiendes las
inscripciones en los periódicos, sabes ya todo lo que hay que saber sobre
el patrón observer. Es lo que llamamos sujeto al editor y observadores a
los suscriptores. Vamos a mirar más de cerca. Ejemplo lisérgico. Tenemos
el objeto sujeto que manda algunos datos de interés. Son mandanteros. Y
entonces, cuando los datos del sujeto cambian, se notifican los
observadores. Tenemos los observadores que están aquí, que han suscrito,
o sea, que se han registrado con el sujeto para recibir actualizaciones.
Cuando cambien los datos del sujeto. Entonces, el objeto ha pensado aquí
en el número 2 y entonces se lo ha mandado a sus suscriptores, que son el
objeto perro, el objeto gato y el objeto ratón. Les ha mandado el 2. Los
nuevos valores de los datos se comunican a los observadores. De la misma
forma, cuando cambian. Este objeto, el pato, no es un observador, por lo
que no es notificado cuando los datos del sujeto cambian. A ver, vamos a
ver un día en la vida del patrón observer y ya os prometo que con esto
terminamos. Dice, un objeto pato viene y le dice al sujeto que quiere
convertirse en observador. Al pato realmente le mola el rollo. Esto es
entero, se lo envía al sujeto cada vez que cambia de estado. Le parece muy
interesante. Entonces, le manda un mensaje, o sea, le llama a un método.
Le registra que es suscriptor. Esto será los observadores antes, el perro,
el gato y el ratón. Y como está escrito, ahora el pato ha aparecido
aquí, entre los observadores. El objeto pato es ahora un observador
oficial. El pato está flipándolo. Está en la lista de espera con
expectación la próxima notificación para conseguir un entero. El sujeto
recibe un nuevo regato. Ahora el pato, entre los observadores, recibe una
notificación de que el sujeto ha cambiado. Le ha mandado un hecho a todos
los animalitos. Entonces, el ratón pide ser borrado como observador. El
objeto ratón ha estado recibiendo enteros una eternidad y ya se ha
cansado. Hola. Ah, vale. Pues el objeto ratón ya se ha cansado y ya decide
que es hora de dejar de ser observador. Entonces, pues, le manda un
mensaje. En programación de entero a objetos. Entonces, en teoría se
habla de mandar un mensaje. Aquí es un momento. Llamar a un método en
Java Borrame o desuscríbeme Entonces el ratón se lo aspira Y ya el objeto
ratón pues ya no está Con el grupo de los observadores Así que la
siguiente vez que el sujeto Tiene insomnio entero Pues le va a llegar al
perro, al pato Y al gato, pero al ratón no Porque ya se ha Se ha borrado Y
si no se lo digas a nadie El ratón está de menos secretamente a estos
enteros Quizá te iba a volver A ser un observador algún día Y vale, este
es el Vamos a dejarlo aquí Que ya queda la hora Pero bueno, esa sería un
poco La idea detrás del Del patrón observador Que luego ya veremos en
más detalle Cómo acaba la historia Hasta las actuaciones meteorológicas
Así que nada ¿Qué os ha parecido esto? Estos PDF que tienes Tú no los
puedes enviar O los puedes dejar en algún sitio O yo que sé Sí, os lo
voy a poner Porque el libro este de Brauer Es un poco duro Además por la
vista del de Brauer Este es un Me lo han dicho otros alumnos Que el tío es
una máquina Que hace De Java pero te lo hace de C Sharp o de lo que sea
Del punto en el El tío coge y te hace El libro ahí de todo Hay gente que
dice que A veces se nota que está reutilizado El libro de otro lenguaje
Pero sí, mira En el Ágora este En el curso virtual Hay un apartado que es
El libro del tutor O algo así Pues en el libro del tutor Si pinchas ahí
Yo puedo poner cosas Entonces pondré las Pondré los PDFs para que así
podáis Repasarlo Yo creo que es un Le enfoca más o menos Que leer un Un
techato ahí de ¿Qué te digo? De la aplicación esa del de Brauer Que era
rellena Pero total Si te ayuda a seguir un poquito Sí, sí Muy bien, pues
Pues nada, ya así Os vais pensando ahí vuestras vidas A ver para el
próximo día y eso Y ya me las preguntáis, ¿vale? De acuerdo, perfecto
Muchas gracias Y finalmente Hasta luego ¡Adiós!