Muy bueno. Particularmente la parte en la que se aclara que el motor es una referencia y no una instanciacion ya que no se pueden utilizar directamente las clases abstractas. Muy educativo.
Excelente video! Muy claro el ejemplo y la explicación. Ahora, me surgió una duda. Qué sucede si la clase MotorElectrico que es legada y quiero adaptar, recibe en algunos o en todos sus métodos diferentes parámetros? Digamos que los métodos de mis clases no los necesitan, pero los métodos de las clases legadas sí. En ese caso qué se hace?
si los métodos de MotorElectrico requieren de parámetros eso se verá reflejado en el UML de dicha clase (agregando tales parámetros), pero la representación de las demás clases no se vería alterada.. por ejemplo, si MotorElectrico requiere de un valor entero para invocar a conectar (que indique una cantidad en voltios, por ejm) ese valor le será pasado al invocar el método dentro del cuerpo de la función encender() de MotorElectricoAdapter, es decir, dichos parámetros tendrían que definirse desde ya dentro de los métodos de MotorElectricoAdapter, ya que justamente su trabajo es adaptar MotorElectrico (definiéndolo para un uso específico)
Programación y más Ok, viéndolo desde el punto de vista de un sistema legado. Cuál sería la clase que viene legada de un sistema desarrollado por otros, MotorElectrico o Motor y sus subclases?
TeeJay Fenix Motor eléctrico sería la clase desarrollada por terceros, por ello tiene distintos métodos, que no concuerdan con la interfaz. Para ello se adapta la clase Motor eléctrico, y de esta forma Motor eléctrico adapter, hace uso de tal clase e implementa los métodos tal cual se necesitan.
Programación y más Retomando el tema de los parámetros, entiendo que deberían pasarse los parámetros dentro de la clase Adapter. El problema es que el adapter sobreescribe los métodos heredados de la clase Motor, y la única forma que veo de llamar al método encender desde afuera con un valor es modificando dicho método en la clase motor, lo cual no me parece apropiado, porque el resto de los motores no lo necesitan. A menos que a la clase adapter le agregue como atributo de instancia un int voltios, y al momento de construir el adapter si o si deba pasarle ese parámetro, entonces dentro del método encender, al llamar al método activar, se le pasaría como parámetro los voltios, . El tema que le veo a esto, es que la clase adapter puede llegar a tener un monton de atributos de instancia que sólo existirían a los efectos de utilizarlos como parámetros en las llamadas de otros métodos, pareciéndose a una bolsa de gatos. Es así como digo o existe otra manera?
Hola!, tengo una duda, porqué no podríamos heredar la clase abstracta Motor en MotorElectrico, y en el propio MotorElectrico definir los métodos abstractos encender, acelerar y apagar, por ejemplo, para encender quedaria algo asi: public void encender(){ this.conectar(); this.activar(); } de esta manera nos ahorrariamos la clase MotorElectricoAdapter.
Hola. Qué bueno que te guste el ajedrez. Sobre tu pregunta, es algo que puedes hacer si eres el autor de la clase. Pero a veces usas bibliotecas / dependencias donde no puedes alterar las implementaciones. En esos casos puedes usar una clase Adapter "para dar forma" según la solución que tienes en tu proyecto 🙂
¿No es posible crear objetos de una clase abstracta? Si es posible, solo que en la llamada del constructor es necesario declarar el cuerpo de los métodos abstractos. Son lo que se llama "clases anónimas", ¿no?
Ajá, sí... pero el objeto que se estaría creando sería justamente un objeto de dicha clase anónima, y no un objeto de la clase abstracta propiamente dicha jeje.
Porque usas el adaptador, si tú implementas la interfaz o la clase la extiendes directamente en la clase de motor eléctrico pues cuando desarrolles encender puedes llamar igualmente a lo que sea porque crear la clase motor adapter que necesidad existe?
Por ejemplo, a veces te pasará que tienes una implementación antigua que necesitas actualizarla, y para esto usarás una nueva biblioteca. Como la nueva es más compleja y no se adapta muy bien a la implementación actual, se crea una clase Adapter, para simplificar esa "conexión" y permitir que todo continúe funcionando. Aquí puedes encontrar más ejemplos: ruclips.net/video/sTDWjzYcZKc/видео.html
La idea del patrón es adaptar una clase a una interfaz que define los métodos que deben adaptarse en ella. En este caso los métodos abstractos se encuentran en una clase abstracta (Motor), que pudo haberse definido como una interfaz (ya que solo presenta métodos abstractos), pero en un ejercicio más realista la clase Motor podría tener métodos concretos y a su vez métodos abstractos que son los que se quieren adaptar en alguna otra clase que no los soporta... en tal caso la clase abstracta reemplaza a la interfaz pero el patrón sigue estando presente.
Muy bueno. Particularmente la parte en la que se aclara que el motor es una referencia y no una instanciacion ya que no se pueden utilizar directamente las clases abstractas. Muy educativo.
Genial. Gracias por el comentario!
Gran explicación. Es definitivamente un canal infravalorado
Gracias por el comentario compañero!
crack, magnifico ejemplo no lo que dan en la universidad que lían más que otra cosa.
+benjamin Garcia Qué bueno que te haya sido útil. Gracias por comentar.
Qué elocuencia para explicar. Felicidades!
Gracias por el comentario! Éxitos compañero.
Esto me salvará mañana en el trabajo. Excelente material
Gracias amigo. Que gran explicacion. Me ha quedado muy claro. Saludos desde Colombia :D
Con mucho gusto. Saludos!
Más claro que el agua imposible.
+10
Excelente! Gracias por comentar.
Me estas salvando!! Si puedes continua con el resto de los Patrones... Gracias
Excelente explicación amigo. Eres el mejor!
Gracias por el comentario!
Saludos 🎅
Gracias por el aporte, buena explicación y buen ejemplo.
Gracias por el video, una explicación muy práctica.
Genial. Gracias por comentar.
Muy clara explicación
Gracias compañero por el comentario!
Gracias por tan buena explicación.
Gracias también colega por comentar!
Me quedó super claro. Muy bien explicado
Excelente! Gracias por comentar.
Hola muchas gracias por tu aporte :-)
Buenísimo, muy bien explicado!
Gracias compañero!
gracias por el video
Gracias también por comentar!
Muy Buen Video me sirvió de mucho Gracias !!!
Excelente video! Muy claro el ejemplo y la explicación. Ahora, me surgió una duda. Qué sucede si la clase MotorElectrico que es legada y quiero adaptar, recibe en algunos o en todos sus métodos diferentes parámetros? Digamos que los métodos de mis clases no los necesitan, pero los métodos de las clases legadas sí. En ese caso qué se hace?
si los métodos de MotorElectrico requieren de parámetros eso se verá reflejado en el UML de dicha clase (agregando tales parámetros), pero la representación de las demás clases no se vería alterada.. por ejemplo, si MotorElectrico requiere de un valor entero para invocar a conectar (que indique una cantidad en voltios, por ejm) ese valor le será pasado al invocar el método dentro del cuerpo de la función encender() de MotorElectricoAdapter, es decir, dichos parámetros tendrían que definirse desde ya dentro de los métodos de MotorElectricoAdapter, ya que justamente su trabajo es adaptar MotorElectrico (definiéndolo para un uso específico)
Programación y más Ok, viéndolo desde el punto de vista de un sistema legado. Cuál sería la clase que viene legada de un sistema desarrollado por otros, MotorElectrico o Motor y sus subclases?
TeeJay Fenix Motor eléctrico sería la clase desarrollada por terceros, por ello tiene distintos métodos, que no concuerdan con la interfaz. Para ello se adapta la clase Motor eléctrico, y de esta forma Motor eléctrico adapter, hace uso de tal clase e implementa los métodos tal cual se necesitan.
Programación y más excelente, gracias!
Programación y más Retomando el tema de los parámetros, entiendo que deberían pasarse los parámetros dentro de la clase Adapter. El problema es que el adapter sobreescribe los métodos heredados de la clase Motor, y la única forma que veo de llamar al método encender desde afuera con un valor es modificando dicho método en la clase motor, lo cual no me parece apropiado, porque el resto de los motores no lo necesitan. A menos que a la clase adapter le agregue como atributo de instancia un int voltios, y al momento de construir el adapter si o si deba pasarle ese parámetro, entonces dentro del método encender, al llamar al método activar, se le pasaría como parámetro los voltios, . El tema que le veo a esto, es que la clase adapter puede llegar a tener un monton de atributos de instancia que sólo existirían a los efectos de utilizarlos como parámetros en las llamadas de otros métodos, pareciéndose a una bolsa de gatos. Es así como digo o existe otra manera?
gracias! muy bien explicado!
Excelente !!!! Felicidades
Gracias por comentar!
Hola!, tengo una duda, porqué no podríamos heredar la clase abstracta Motor en MotorElectrico, y en el propio MotorElectrico definir los métodos abstractos encender, acelerar y apagar,
por ejemplo, para encender quedaria algo asi:
public void encender(){
this.conectar();
this.activar();
}
de esta manera nos ahorrariamos la clase MotorElectricoAdapter.
Hola. Qué bueno que te guste el ajedrez.
Sobre tu pregunta, es algo que puedes hacer si eres el autor de la clase.
Pero a veces usas bibliotecas / dependencias donde no puedes alterar las implementaciones.
En esos casos puedes usar una clase Adapter "para dar forma" según la solución que tienes en tu proyecto 🙂
@@programacionymas De acuerdo!, Muchísimas gracias por tu explicación, no hay mucha gente que deje las cosas tan claras, un saludo amigo 😉.
Eeeeeeeeeeepica explicación.
Gracias!
¿No es posible crear objetos de una clase abstracta?
Si es posible, solo que en la llamada del constructor es necesario declarar el cuerpo de los métodos abstractos. Son lo que se llama "clases anónimas", ¿no?
Ajá, sí... pero el objeto que se estaría creando sería justamente un objeto de dicha clase anónima, y no un objeto de la clase abstracta propiamente dicha jeje.
Muy bueno!
Gracias por comentar.
Excelente!!!
buena explicacion
gracias!
Porque usas el adaptador, si tú implementas la interfaz o la clase la extiendes directamente en la clase de motor eléctrico pues cuando desarrolles encender puedes llamar igualmente a lo que sea porque crear la clase motor adapter que necesidad existe?
Por ejemplo, a veces te pasará que tienes una implementación antigua que necesitas actualizarla, y para esto usarás una nueva biblioteca. Como la nueva es más compleja y no se adapta muy bien a la implementación actual, se crea una clase Adapter, para simplificar esa "conexión" y permitir que todo continúe funcionando.
Aquí puedes encontrar más ejemplos: ruclips.net/video/sTDWjzYcZKc/видео.html
Me explicaron este ejemplo, me viven repitiendo que este caso la clase abstracta Motor tiene que ser una interfaz. Por que ?
La idea del patrón es adaptar una clase a una interfaz que define los métodos que deben adaptarse en ella. En este caso los métodos abstractos se encuentran en una clase abstracta (Motor), que pudo haberse definido como una interfaz (ya que solo presenta métodos abstractos), pero en un ejercicio más realista la clase Motor podría tener métodos concretos y a su vez métodos abstractos que son los que se quieren adaptar en alguna otra clase que no los soporta... en tal caso la clase abstracta reemplaza a la interfaz pero el patrón sigue estando presente.
Muchas gracias por la explicacion y razonamiento, amigo. !