Gracias por el video, Manuel. Yo uso las clases abstractas para representar "jerarquías de comportamiento" y las interfaces como "contratos comportamentales". Pensarlo de esa forma me ayuda a elegir una u otra. Mis dilemas: - Librerías livianas o pesadas para el frontend (Ractive o Mustache vs. Angular o React). Prefiero las primeras. - SQL u ORM. Solía preferir la segunda, pero ahora estoy más con la primera. - Code First vs. Database First. Solía preferir la primera. - Enum vs. Constantes vs. Parámetros en la BD. Todo un dilema. - Más frameworks sobre el framework (ej. Prism sobre Xamarin). Aunque dicen que simplifican muchas cosas, nunca me han llamado la atención.
Me gusta tu diferenciación de jerarquías de comportamiento y contratos comportamentales. En cuanto a tus dilemas, son muy interesantes y pasan mucho. Creo que uno de los proximos será "SQL y ORMs" o "enums, constantes y parámetros en la BD". Graciad por el comentario!
@@ManuelZapata Yo ultimamente uso mucho enum para definir constantes. La ventaja es que podes crear constantes ESPECIFICAS como parámetros para metodos, entonces te ahorras el posible problema de que si alguien usa tu metodo, le meta un parametro para el cual no hay caso contemplado. Soy nuevo en esto, asi que no se si lo estoy usando bien.
¿ que diferencia hay entre "jerarquías de comportamiento" y "contratos comportamentales" ? me parece exactamente lo mismo pero con diferentes palabras.
@@tranquiloteov Cuando hay una clase abstracta A, y B hereda de ella, se genera una jerarquía: B es A. Pero si tienes una interfaz C, y D la implementa, entonces D "cumple con el contrato C", pero no es C.
Una diferencia que aún existe es que la clase abstracta puede tener estado (variables de clase) y la interface no puede tenerlo. Además en algunos casos la clase abstracta puede ser muy útil, como por ejemplo al implementar el patrón template method y solo delegar y obligar a las clases hijas a implementar la parte abstracta del template method.
Clase Abstracta: 1.Atributos (Variables de Instancia): Mantienen el estado de los objetos. 2.Constructores: Utilizados para inicializar variables de instancia en las subclases. 3.Métodos Concretos: Proporcionan una funcionalidad base común. 4.Métodos Abstractos: Deben ser implementados por las subclases concretas. Interfaces: 1.Definición de Métodos Abstractos: Contratos de comportamiento sin implementación (hasta Java 7). 2.Constantes: Variables en interfaces son implícitamente public, static, y final. 3.Métodos por Defecto: Métodos con implementación desde Java 8, permiten la evolución de la interfaz sin romper el código existente. 4.Métodos Estáticos: Métodos que pueden ser llamados sin instancias. 5.Herencia Múltiple: Una clase puede implementar múltiples interfaces. 6.No Puede Tener Estado: No puede mantener variables de instancia.
Interesante... no sabía lo de los default methods en las interfaces. Estoy de acuerdo contigo. Las interfaces, a menos que queramos compartir funcionalidad entre clases concretas (aunque ya con los default methods no aplicaría mucho este argumento), siguen siendo más flexibles y limpias.
Gracias por tu comentario, Wil! Sí, el tema de los default methods ha ido tomando relevancia poco a poco. A mi personalmente no me convencen, pero eso es otro tema.
Estoy desarrollando un videojuego implementado los principios SOLID y llegué a este a dilema jajaja, gracias. Me aclaraste muchas dudas, por más que ya sabía los conceptos a veces necesito que alguien me dé un empujoncito jeje
A mi me gusta el siguiente ejemplo: "Si tu pato de hule puede volar no estas utilizando la abstracción correcta." En ese ejemplo existen 2 objetos uno un pato de carne y hueso y el otro un pato de hule, se define la clase abstracta ave, porque lo que me interesa no es una instancia de un ave, sino un pato de hule o un pato de carne y hueso, el dilema de la interfaz se resuelve fácil en este ejemplo ya que si en la clase abstracta definimos el método volar cometeremos un error por permitir que un pato de hule que hereda de la clase abstracta ave tenga una acción que no es capaz de implementar. Entonces ahí es donde aparece la interfaz, se crea la interfaz volar o volador, y cada objeto ve si la implementa.
Hola, muchas gracias, con este ejemplo de verdad me quedó mucho más claro. Lo pongo en mis palabras: Si por ejemplo tengo una tienda de animales y además vendo juguetes de animales. Si creo una Clase Abstracta Ave que tiene un comportamiento o método Volar() a la clase Pato la extiendo y queda muy bien pero a la Clase Pinguino y a la Clase PatoHule si le extiendo la clase abstracta estoy poniendo un comportamiento que realmente ese objeto no puede hacer. En este caso es mejor crear interfaces IAnimalVolador y IJugueteVolador y cada clase implementa o no la interfaz si es que la necesita. Saludos.
Muy buen video, me acabo de enterar que las interfaces permiten métodos por defecto, que no parecen ser muy distintos a los métodos virtuales, las clases abstractas te permiten tener campo y propiedades, no sé si las interfaces. Creo que usar una clase abstracta o interfaces es asunto de semantica, la clase abstracta significa en muchos casos qué se está implementando algoritmos y que la subclase puede implementar una parte del mismo, comparten responsabilidad. Y la interfaz solo te avisa del contrató, si estás usando un framework o tienes una arquitectura plugin talvez tengas que heredar de una clase abstracta y podrás usar campos que Delos que no tienes acceso pero la clase abstracta si, ayuda a la ocultación sin quitar funcionalidad. La interfaz es solo el contrato y eso es muy bueno.
Hola gracias por el vídeo, me aclaró algunos conceptos. Actualmente uso clases abstractas cuando quiero que un objeto tenga un comportamiento por defecto que lo define conceptualmente, pero cuyos herederos deben definir una parte específica. Por ej. un service provider (abstracto), puede tener comportamiento y métodos para interactuar con un IoC container, pero las implementaciones concretas deben implementar métodos para vincular los servicios (esto es, los objetos, funciones, etc.) a sus identificadores (por ej. nombre de clase/interfaz, palabra clave, etc.).
master, como siempre excelente información, yo personalmente creo que esta incertidumbre se da sobretodo cuando no hay un diseño previo. yo utilizo las interfaces sobre todo para la implementación de patrones de diseño y para temas de contratos de funcionalidad,
Las interfaces pueden tener propiedades(campos o atributos)? en c# puedo hacer esto en una interface (int Name {get; set;} eso lo veo como una propiedad y me cofundio un poco.
Hola Manuel, particularmente yo prefiero usar clases abstractas cuando puedo tener métodos que las clases hijas pueden usar, las interfaces las uso como contratos para los consumidores de las clase, con SOLID el uso de interfaces es muy fuerte. Saludos y gracias por los videos
Excelente video muy claro en cuanto a las "diferencias". También prefiero la flexibilidad de interfaces y comparto con que todo nace de un buen diseño, caso contrario nos ponemos a divagar y podemos pasar mucho tiempo en si lo uno o lo otro. Mi dilema SQL vs ORM actualmente utilizo SQL, otra JavaEE vs Spring 😬😬 esas principalmente, saludos hermano desde Ecuador
Hola Francisco. Aún si el lenguaje de programación lo permite, yo nunca pondría propiedades es una interfaz. Me parece que solo se deben usar para modelar comportamientos y no datos. Saludos!
hola, creo uno de los puntos más sustanciales entre Arq y dev es saber interpretar el uml a código diferencias entre composición, agregación... como se codifican lo que el Arq diseña
Bueno tuve que utilizar una interface en una clase abstracta, ya que tenía productos que compartían exactamente la misma lógica de negocio y también tenía mis excepciones. Bueno sobre estás reglas excepcionales simplemente sobrescribí. Esto me sirvió para evitar mucho código duplicado, pero también me trae un problema difícil de percibir, ya que si sobrescribes mal el método de la clase abstracta, pues irá a buscar el método de la clase padre y no te darás cuenta que no estás trabajando con el método sobrescrito y su funcionalidad, ya que la clase abstracta es muy difícil de rastrear a la primera.
En la practica me va super bien, pero en la teoria horrible, he perdido algunas oportunidades por no tener propiedad al responder una pregunta de este tipo, gracias por esta información.
Que sentido tiene definir una Interfaz como atributo de una clase?, o he visto que hay métodos que retornan interfaces, no entiendo?.. Muchas gracias por tu ayuda
Me gustaría que hicieras un video sobre los árboles de expression es algo como esto: List GetList (Expression expression). Entiendo todo lo que está ahí menos la palabra Expression antes del delegado Func.
Hola Yerson, te recomiendo que visites el canal de nuestro amigo Héctor de León. Tiene contendo super extenso en C# y quizá pueda ayudarte. Saludos! ru-vid.com/show-UCDUdeFslCNoM29MAlZOfdWQ
las interfaces sin dudas ofrecen una flexibilidad mucho mayor y con la posibilidad de definir comportamiento general en ellas con los default methods no veo razon para volver a usar clases abstractas a menos que se de un caso muy particular
Alguna vez tuve un Dilema y era, usar bases de datos documentales como las que me ofrece Firebase de Google o usar las de EERR tradicionales como las de MySQL, PostgreSQL y demás, la verdad a veces no sabía cuando usar una u otra.
Hola, enhorabuena por su canal, he visto algunos videos y me han sido de gran ayuda, pero tengo un dilema, al hilo de las clases y métodos "static" en la web... ¿podría haber datos cruzados entre 2 usuarios por ejemplo, que se conectasen a la vez? ¿o sería el servidor el que creara distintos "espacios de trabajo" (no se como llamarlo) para cada usuario con sus propios ensamblados? no se si me he explicado bien, un saludo y gracias
Eso depende mucho de la implementación Despo. De como utilices el contexto de la aplicación web y como manejes las sesiones. Ambos escenarios pueden ocurrir. Saludos!
Hay varios escenarios, Diego Bermudez. El más común es que uses la interfaz para indicar que una clase tiene cierto comportamiento. Por ejemplo, cuando en Java usas la interfaz Serializable, indicas que la clase tiene la capacidad de ser serializada.
Yo me veo muchas veces haciendo interfaces vacías porque me sirven para tratar varias clases como respuesta de un método o como argumento. Y la verdad me hace algo de ruido pero no se me ocurre como evitarlo.
Hola, yo siempre he tenido está duda: ya ven que dicen que no hay que repetir tanto código. Y mi pregunta es: ¿Cuánto es lo máximo o lo mínimo que se puede repetir código que se podría considerar correcto? Por ejemplo en este caso de las interfaces muchas veces se tiene que repetir código al implementarlas
Si estás repitiendo mucho código cuando implementas las interfaces, seguramente te falta una clase base que implemente la interfaz. Luego, de esa clase base, pueden heredar las demás.
Muy buena Manuel esta sección con pequeños tips. A me gustaría que trates el tema de bloqueos en BDs. Recuerdo hacer en vb6 bloqueos optimistas y pesimistas. Y me gustaría saber cómo evoluciono eso, si es necesario en ciertas aplicaciones, si pasa a hacer parte de la función de un gestor de BDs. Bueno nada eso, espero verte en un video al respecto. Saludos.
muy buen video. Aunque no logro entender que sentido tienen las interfaces cuando no podías crear métodos por defecto. Supongamos que tengo un programa que sé de antemano que va a ser muy grande. Y tengo una serie de operaciones que quiero pre definir para que se hagan de la misma manera en todo el programa. Cual sería la mejor manera de implementar eso? Viendo este video, una interfaz con los métodos default de por ej: compra-venta, y luego implementar eso en las clases que necesiten realizar operaciones o modificaciones. Pero de la forma anterior, si yo creara esa interfaz solo podría declarar los métodos y no definirlos. Por lo que tendría que en cada implementación de esa interfaz definir todos los métodos de esa interfaz. Si eso es así, que sentido tiene tener la interfaz, de todas maneras tendría que definir el método en todas las clases. La única ventaja que le veo es que obligarías a todas las clases a implementar todos los métodos, por lo que habría cierta uniformidad...
Es muy buena tu pregunta. Aún sin métodos por defecto, las interfaces siguen teniendo muchísimo valor. Su principal objetivo es definir el comportamiento que se espera tengas las clases que la implementan. Las interfaces no están pensadas para reusar el código dentro de los métodos. Para esto, puedes crear clases normales o clases abstractas. Ahora, cuando dices "Supongamos que tengo un programa que sé de antemano que va a ser muy grande. Y tengo una serie de operaciones que quiero pre definir para que se hagan de la misma manera en todo el programa. Cual sería la mejor manera de implementar eso?". Esto no requiere una interfaz. Puedes usar otras herramientas. La interfaz te sirve cuando vas a tener múltiples maneras de hacer algo.
Me gustaría abordar el tema de realizar un software extensible por tercero. En concreto extensible tanto en el lado del cliente como el del servidor. Estoy pensando en un esquema UI (Vue) + API (REST). Como hacer que los terceros puedan realizar plugins? y otro dolor de cabeza, En el servidor? en el cliente? y donde ubicar la logica de negocio base? y si luego quieren extenderla.. -_-' como vees.. tengo un lio con la arquitectura core y su futuro XD
Buenos dilemas! Por aquí 3 videos que pueden ayudarte: Arquitectura de plugins: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-BQ6ydks56D8.html Consejos para mejorar la lógica de negocio: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-fdnqf0qZUbw.html ¿Lógica de negocio en el cliente o en el servidor? ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-SPmbxvvT7Aw.html
@@ManuelZapata ¡Hola Muchas gracias por tu rápida respuesta y felicidades por el contenido del canal, es de alta calidad y genial! Hacía falta algo así. La conclusión del video, la cual comparto, es que la lógica de negocio idealmente debería estar en el servidor. Por temas de control, no duplicidad, etc.. Allí incluso se puede realizar el patrón hook o plugin. El problema y la duda que no he sabido resolver en tus videos, es como conseguir esto con un modo desconectado. Como solucionarías tu este problema? ¿Conoces algún patrón de ejecución de lógica online, offline y posterior sincronización? ¿O transporte de lógica para trabajar offline sin duplicar? Yo le doy vueltas a algo así como crear una encapsulación de lógica de negocio offline, la cual implemente comportamiento online, comportamiento offline y su posterior sincronización. La cosa es que se acerca mucho a la peor de las soluciones, la distribución de la lógica de negocio entre cliente y servidor, y esta historia evoca un trágico final. XD XD Ideas? ¿Patrones? :’(
hola muchas gracias, me gustaria saber como utilizar en java, los componentes de un jframe en otras clases, sin necesidad de volverlos publicos, es decir tengo en mi jframe una tabla, pero quiero que todos los metodos de llenar, consultar, borrar etc, no esten dentro del jframe sino en otra clase aparte y que actualice el jframe en tiempo real, al ejecutar dichos metodos. gracias nuevamente
Hola Alvaro, Lo que yo haría es crear una clase interna en el JFrame, y creo un getter para obtenerla. Al ser la clase interna, podría acceder algunos los objetos privados o protegidos en el JFrame sin tener que exponerlos. Qué opinas? Si ya lo resolviste, sería interesante saber como lo hiciste.
@@ManuelZapata muchas gracias, aún no lo he resuelto, pero se me ocurrió crear una clase aparte que reciba como parámetro el jframe y desde esa clase manipular los elementos, y hacer los getters y setters necesarios. Pero como no te digo aún no lo resuelvo, sólo es una idea que no he probado
Que alguien me saque de la duda, ¿se puede usar la inyección de dependencias pasando una clase abstracta en vez de una interfaz? De entrada pensaría que no es lo mismo, pero puedo estar equivocado.
Muy buen vídeo. Pero creo que cabe aclarar que las interfaces no tiene propiedades, las clases abstractas si tienen propiedades, en el caso de Java y C#. Esta puede ser una diferente sustancial. y en algunos lenguajes de programación como Dart, cuando extiendes de una clase abstracta, la clase derivada debe implementar los métodos y las propiedades, es bastante curioso.
Hola q tal, tengo una duda, pero es sobre instanciar objetos. Por ejemplo creo la clase Empleado a la cual le digo q implemente la interface Comparable, la cual ya esta construida en la api de java. Cual es la diferencia de instanciar un objeto de estas 2 formas: Empleado elnuevo=new Empleado(); O de esta forma Comparable elnuevo=new Empleado();
Hola @Walter. El tipo que le pongas a la variable te define los métodos y atributos que podrás usar, SIN tener que hacer un cast. Por ejemplo, si la variable es de tipo Comparable, podrías llamar el método compareTo(). Si la variable es de tipo Empleado, podrías llamar métodos como getNombre, getApellido. Espero que te haya quedado claro.
Me refiero a la variable elnuevo, @@walterjosesuarezdelacruz1495. Dependiendo del tipo con que la declares (Comparable o Empleado), así mismo serán los métodos que podrás usar. Pero en ambos casos, será un objeto Empleado. Bienvenido al canal!
Mi principal problema es para resolver los problemas, la parte de codificarlo ya es mucho mas sencilla, como puedo mejorar mi capacidad de resolver problemas?
No te tengo una respuesta exacta, pero te puedo contar algunas cosas que me han servido: 1. Pensar el problema en términos de entradas, salidas y proceso. 2. Dividir el problema en partes y no tratar de abarcarlo todo de una. 3. Pensar primero en la solución antes de tocar una sola línea de código. 4. Practicar mucho.
Hola mi problema es que no entiendo como sirve realmente esto de la iterface porque no en tido com hago para conectar lo que es la clase y la iterface es decir tengo la clase persona con sus atributos metodos y propiedades y codigo que ejectutan tales o cuales acciones bien esto esta bien ahora creo la iterface IPersona con sus porpiedades y metodos de Calse persona ok hasta aca bien, pero creo una clase Empleado y a esta le quuiero implementar la clase Persona pero lo hacemos por la interface pero que pasa creo la clase Empleado todo bien con la implementacion de porpiedaes y metodos de iPersona pero y elcodigo que tengo en Clase persona no me aparece como se utiliza como se conecta realmente con la clase Persona la cual tiene el codigo de los procedimientos etc. Espero se me halla entendido dejo un codigo de lo que tengo: VB Public Class ClasPersona Private _Nombre As String Private _Apellido As String Private _FechaNacimiento As Date Private _Edad As Integer Public Property Nombre As String Get Return _Nombre End Get Set(value As String) _Nombre = value End Set End Property Public Property Apellido As String Get Return _Apellido End Get Set(value As String) _Apellido = value End Set End Property Public Property FechaNacimiento As Date Get Return _FechaNacimiento End Get Set(value As Date) _FechaNacimiento = value Call CalculoEdad() End Set End Property ReadOnly Property Edad As Integer Get Return _Edad End Get End Property Public Sub CalculoEdad() _Edad = (Now.Year - _FechaNacimiento.Year) End Sub End Class Public Class CEmpleado : Implements IPersona Private _Nombre As String Private _Apellido As String Private _FechaNacimiento As Date Private _Edad As Integer Public Property Nombre As String Implements IPersona.Nombre Get Return _Nombre End Get Set(value As String) _Nombre = value End Set End Property Public Property Apellido As String Implements IPersona.Apellido Get Return _Apellido End Get Set(value As String) _Apellido = value End Set End Property Public Property FechaNacimiento As Date Implements IPersona.FechaNacimiento Get Return _FechaNacimiento End Get Set(value As Date) _FechaNacimiento = value End Set End Property ReadOnly Property Edad As Integer Implements IPersona.Edad Get Return _Edad End Get End Property Public Sub CalculoEdad() Implements IPersona.CalculoEdad End Sub End Class lo que no entido es que la implementacion solo me crea la estructura de pero y como se implementa la clase Persona que si tien el codigo, es lo que tengo un rollo en la cabeza
Hola Marco, estos temas de herencia al comienzo pueden ser confusos. En caso de que aún tengas confusión con esto, te recomiendo el tercer video de mi mini curso de objetos: manuelzapata.co/mini-curso-programacion-profesional-objetos/
Cuando recien estas aprendiendo sobre programacion y terminas aqui.... Creo que voy a tocar con los musicos del titanic mejor.... jajajaj No mentiras quiero alcanzar el nivel de dominar estos temas para aplicarlos; Voy en aprendizaje de POO.
Yo tengo un dilema XD, en una arquitectura N capas, factory tendría su propia capa? o debería ir dentro de la capa domain como paquete independiente al core? Yo lo hice de la segunda manera.
