BettaTech, desde el punto de vista profesional sos EL MEJOR o DE LOS MEJORES canales de programación, todas cosas útiles y cero humo, deberías tener muchísimas más views...
Es curiosa la forma que se aplica. Conocia las máquinas de estados desde que las usé en el desarrollo de sistemas en chip (en FPGA), cómo verás son sistemas críticos donde no se toleran los fallos. Es una forma curiosa que no conocía y que voy a profundizar más. En este caso se usan máquinas de tipo moore, para una mealy sería necesario separar las tareas del software en dos partes que serían la que gestiona los estados y la que gestiona las salidas. Esto se usa en lenguajes concurrentes como Erlang. También cabe recalcar que tiene el inconveniente de que acompleja demasiado el código siendo poco viable para proyectos que no necesitan tanta robustez y que en su lugar necesitan ser facilmente mantenibles.
2 cosas primero banco tu contenido un montón me gustan tus vídeos el tema es que el ejemplo que das no tiene una comparación sin tipado. Básicamente lo mismo es aplicable en js(este caso en concreto), hubiese estado interesante que muestres como se manejaría el error a la hora de instanciar ConnectedSocket. Y ejemplos de los test que se ahorrarían. El concepto esta bueno pero la resolución no la senti clara.
Como concepto esta interesante, pero y si la coneccion se pierde mientras tienes el objeto ConnectedSocket? Ahi que haces? no me quedo claro o si ConnectSocket no se logra conectar que? Entiendo el punto de que te ahorras los tests del unhappy path, pero sigue sin quedarme claro como seria el manejo de errores, porque al final pues tendrias que testear que se conecte o no, que hacer cuando se pierda la connecion tambien. Teoricamente los unhappy path siguen ahi por la naturaleza misma de los websockets.
No creo que sea buena idea hacer un objeto por estado de conexión porque no es algo que nosotros controlemos. Si tienes una copia del objeto SocketConnected pero la conexión fue cerrada desde el otro extremo o te quedaste sin Internet, el código no lanzó el evento a tiempo y tú estás usando un objeto incorrecto y te dará un error de ejecución difícil de anticipar porque te confiaste mucho en que los tipos te resolverían el problema.
Enhorabuena por el vídeo, ya que es muy interesante.Este tipo de vídeos son los mejores que haces Martín, no dejes de hacerlos a pesar de tu nuevo proyecto con The Commit Show.
Muy interesante video, sin embargo de inmediato se me ocurrió una forma de poder extender este patrón de diseño, y que creo que habría sido interesante mencionar: class InternalSocket { // Aquí puede poner información compartida que no se quiera duplicar en cada cambio de estado. // es posible poner todos los miembros publicos y evitar los problemas de encapsulamiento dejando la clase // sin exportar .... } export class ConnectedSocket { constructor(private internal : InternalSocket) {} disconnect() : DisconnectedSocket { .... } .... } export class DisconnectedSocket { constructor(private internal : InternalSocket) {} connect() : ConnectedSocket { ..... } }
¿Una solución al problema de la creación de múltiples objetos no sería extraer el comportamiento de cada estado a una interfaz y en los métodos de transición de estado retornar `this` y en la signatura del método especificar que se está retornando un objeto del tipo de la interfaz? Además, para estar completamente seguro de que se usará el estado retornado y no la referencia al objeto original, se podría tener una variable con estado interno. Sería una comprobación en tiempo de ejecución, pero idealmente la gente usará la referencia retornada en el método de transición para sacarle el máximo provecho al sistema de tipos. No sé si haya alguna forma de invalidar una variable, como por ejemplo en Rust consumiéndola. No soy muy experimentado en TypeScript. 😅
Me gusta bastante la idea de reutilizar el mismo objeto y usar cada estado como una interfaz, me sorprende que se te haya ocurrido si no tienes experiencia en Typescript (a mi me confundió bastante el _ducktyping_ de TypeScript, porque yo vengo de C++).
Si te he entendido bien (puede que no), sugieres utilizar una especie de SuperState con la implementación de todas las posibilidades de la máquina de estados, y tener las ventajas de validación estática. Esa idea tiene muchos problemas a la hora de mantener el código: En la gestión de cada acción o de las transiciones, tendrías que discriminar la acción a realizar en función del estado interno. Creo que no existe ninguna forma de verificar que lo que si el tipo/interfaz dice que se puede realizar una determinada acción o transición, realmente sea así y al final necesites hacer exactamente los mismos tests que si no tuvieras tipado. Posibilidades para gestionar las ramas de ejecución según la variable de estado dentro de cada método: - Hacer múltiples if-else según el estado. Si añades un nuevo estado, no hay nada que te obligue a implementar esa rama. Si lanzas un else genérico que no haga nada o lance un error, es una comprobación en ejecución. Si quitas un estado, tampoco te avisa directamente de que el estado no existe, tendrías que borrar el identificador del estado primero. Tampoco creo que haya forma de vincular estáticamente la existencia de un estado con la existencia de su identificador (lo cual puede derivar en identificadores que no se usen o en ramas de estados que ya no existen). - Hacer un switch soluciona algunos problemas, porque se puede obligar a que existan los 'case' para todos los identificadores poniendo en el caso default un check con un tipo 'never'. Pero mantiene el resto de problemas de if-else. Añade también otro problema de error humano, y es el olvido de break/return de algún caso. En ambos casos, hay que tener en cuenta que tanto para añadir comportamiento como para modificarlo, hay que tocar código existente (sí, añadir un case o un if-else es modificar código existente). Con esto básicamente te estás saltando el principio de Open-Closed. No quiere decir que la solución no vaya a funcionar, sino que probablemente más pronto que tarde va a dar problemas de mantenibilidad por errores humanos. Por lo que la mejor idea que se me ocurre es hacer la implementación de cada estado por separado y añadirla al SuperState, de modo que con polimorfismo, se llame simplemente al método del estado actual y no haya que hacer esta comprobación con identificadores. El problema es que aún así, hay que gestionar los casos en los que no exista la acción o el cambio de estado (lanzando un error, no haciendo nada...) para cada estado, teniendo también en cuenta que esto puede cambiar a futuro y quieras que métodos que no debían funcionar funcionen y al revés, y no haya forma estática de comprobar que efectivamente estén implementadas. Esto dice a gritos que estamos incumpliendo el Principio de sustitución de Liskov (LSP). O sea, que tenemos el problema que básicamente te he descrito. Si se puede solucionar de alguna manera, no se me ocurre. Si a ti se te ocurre, te invito a compartirlo. Estoy implementando una solución propia para la Máquina de Estados en TypeScript basado en lo que BettaTech menciona en el vídeo, y que gestiona la invalidación de instancias de estados anteriores. Si te interesa, dímelo y pongo aquí el repo cuando la haya terminado. Y perdón por la parrafada. Estas cosas son más complejas de lo que a veces parecen xD
¡Gran video! Como aporte, con Rust se puede usar PhantomData para manejar estados, lo cual permite que una estructura (las "clases" de Rust) implemente métodos distintos dependiendo de su estado, ya que para Rust son tipos diferentes. Lo mejor de todo es que en este lenguaje el tamaño de las estructuras es igual a la suma del tamaño de sus atributos, por lo que si nuestros estados son estructuras sin atributos, da como resultado que el uso de estados es una abstracción a costo 0.
Con el patrón state puedes encapsular la implementación interna de las clases en una interfaz execute siempre que el lenguaje permita polimorfismo. ¿No? Y así te evitas que se conozca la implementación de todo quisqui. Quizá aquí habla un programador java de más, ¿Eh?
Una pregunta BettaTech. Quiero ser backend y sabes que para uno resolver problemas en un lenguaje específico, se necesita aprender estructura de datos y algoritmos, pero ¿puedo aprender las funciones que traen los lenguajes para esas estructuras de datos o aprenderla tal y como hacen los tutoriales?
Cómo bien se ve en el minuto 1:11, python no es un lenguaje de tipado estático, lo que según leí, lo inhabilita para hacer TyDD (type-driven development). Sin embargo me pregunto si no se podrá hacer algo parecido de todas formas con bibliotecas como pytyped o pytype. 🤔
hola! excelente video! consulta, en el minuto @11:39, se muestra la definicion de la clase websocket con el atributo #state, que hace el numeral o gato antes de un atributo en typescript?
La parte que no entiendo es porque esto nos hace tener menos test? ahora tenemos 2 componentes que probar, y ademas tenemos que modificar la logica que use a este sockets para que tenga que gestionar estos dos tipos de objetos a menos que usemos un orquestador de "estados" que gestionaria estos dos tipos de objetos (ya que ahora cada objeto es la representación de un estado) y tendriamos que hacerle test tambien enfocado en comprobar que el orquestador funcione de manera correcta, entonces no se si para este ejemplo sea el mejor de los casos, ya que si, se fuerza al flujo a que los metodos esten mas segregados aun (un objeto se encarga de gestionar la creacion y otro la conexion) pero pues a la larga estamos es escalando la complejidad y quien use esto, debe incluir el test del manejo de estos "estados"
La cosa está en que te ahorras todos los test tipo: "Debe dar error si se intenta emitir un evento sin haber conectado", porque de eso se encarga el sistema de tipos. Directamente no te compila porque es imposible ese estado. Ningun test podra testear que eso sucede (que se emite un error) porque es un estado imposible. No digo que elimine TODOS los test, pero si los que son inútiles (nunca deberias poder hacer eso que estás testeando para que no pase)
Excelente, que calidad. Cada video es mejor que el anterior en cuanto a calidad de producción... Y los conocimientos bueno tu sabes qu eso es variado pero al final no hay desperdicio en ello!
Hacer cinco céntimos es un catalanismo que no creo que tenga traducción al castellano estándar y no sé qué entenderán los del resto del territorio español
...pues yo soy experto y me es bastante útil, no entiendo por qué ésa aseveración Tampoco sé si entiendo por qué "destruye a los programadores novatos", no me parece que sea más complejo que Java, que muchas veces es el primer lenguaje que se les enseña a los novatos.
Por un momento pensé que mi pantalla estaba rota, que susto jaja
+1
nunca me imagine que las maquinas de estado se pudieran usar asi, que buen trabajo Betta ! Como que una luz se me ilumino jaja
Gracias!!!!!!
BettaTech, desde el punto de vista profesional sos EL MEJOR o DE LOS MEJORES canales de programación, todas cosas útiles y cero humo, deberías tener muchísimas más views...
Muchisimas gracias!!!!!!!
Es curiosa la forma que se aplica. Conocia las máquinas de estados desde que las usé en el desarrollo de sistemas en chip (en FPGA), cómo verás son sistemas críticos donde no se toleran los fallos. Es una forma curiosa que no conocía y que voy a profundizar más.
En este caso se usan máquinas de tipo moore, para una mealy sería necesario separar las tareas del software en dos partes que serían la que gestiona los estados y la que gestiona las salidas. Esto se usa en lenguajes concurrentes como Erlang.
También cabe recalcar que tiene el inconveniente de que acompleja demasiado el código siendo poco viable para proyectos que no necesitan tanta robustez y que en su lugar necesitan ser facilmente mantenibles.
2 cosas primero banco tu contenido un montón me gustan tus vídeos el tema es que el ejemplo que das no tiene una comparación sin tipado. Básicamente lo mismo es aplicable en js(este caso en concreto), hubiese estado interesante que muestres como se manejaría el error a la hora de instanciar ConnectedSocket. Y ejemplos de los test que se ahorrarían. El concepto esta bueno pero la resolución no la senti clara.
Como concepto esta interesante, pero y si la coneccion se pierde mientras tienes el objeto ConnectedSocket? Ahi que haces? no me quedo claro o si ConnectSocket no se logra conectar que? Entiendo el punto de que te ahorras los tests del unhappy path, pero sigue sin quedarme claro como seria el manejo de errores, porque al final pues tendrias que testear que se conecte o no, que hacer cuando se pierda la connecion tambien. Teoricamente los unhappy path siguen ahi por la naturaleza misma de los websockets.
Me encanta que haya gente como tú haciendo contenido más técnico. ¡Muy interesante!
La velocidad de tus explicaciones es la justa y necesaria.
No creo que sea buena idea hacer un objeto por estado de conexión porque no es algo que nosotros controlemos. Si tienes una copia del objeto SocketConnected pero la conexión fue cerrada desde el otro extremo o te quedaste sin Internet, el código no lanzó el evento a tiempo y tú estás usando un objeto incorrecto y te dará un error de ejecución difícil de anticipar porque te confiaste mucho en que los tipos te resolverían el problema.
Intentan simplificar un problema generando muchos más
Enhorabuena por el vídeo, ya que es muy interesante.Este tipo de vídeos son los mejores que haces Martín, no dejes de hacerlos a pesar de tu nuevo proyecto con The Commit Show.
Muchisimas gracias!!! Ahi seguiran😁
Esta explicación me gusto mucho porque justo estoy estudiando patrones de diseño usando Java
Muy interesante video, sin embargo de inmediato se me ocurrió una forma de poder extender este patrón de diseño, y que creo que habría sido interesante mencionar:
class InternalSocket {
// Aquí puede poner información compartida que no se quiera duplicar en cada cambio de estado.
// es posible poner todos los miembros publicos y evitar los problemas de encapsulamiento dejando la clase
// sin exportar
....
}
export class ConnectedSocket {
constructor(private internal : InternalSocket) {}
disconnect() : DisconnectedSocket {
....
}
....
}
export class DisconnectedSocket {
constructor(private internal : InternalSocket) {}
connect() : ConnectedSocket {
.....
}
}
Genial! Muy interesante ver como aplicar patrones de diseño en el mundo real y derivados de estos.
Como idea no está mal, pero... ¿Y si falla la conexión del socket?
Excelente video me gusta cuando se habla de tecnología de manera un poco mas técnica
¿Una solución al problema de la creación de múltiples objetos no sería extraer el comportamiento de cada estado a una interfaz y en los métodos de transición de estado retornar `this` y en la signatura del método especificar que se está retornando un objeto del tipo de la interfaz? Además, para estar completamente seguro de que se usará el estado retornado y no la referencia al objeto original, se podría tener una variable con estado interno. Sería una comprobación en tiempo de ejecución, pero idealmente la gente usará la referencia retornada en el método de transición para sacarle el máximo provecho al sistema de tipos. No sé si haya alguna forma de invalidar una variable, como por ejemplo en Rust consumiéndola. No soy muy experimentado en TypeScript. 😅
Me gusta bastante la idea de reutilizar el mismo objeto y usar cada estado como una interfaz, me sorprende que se te haya ocurrido si no tienes experiencia en Typescript (a mi me confundió bastante el _ducktyping_ de TypeScript, porque yo vengo de C++).
Si te he entendido bien (puede que no), sugieres utilizar una especie de SuperState con la implementación de todas las posibilidades de la máquina de estados, y tener las ventajas de validación estática. Esa idea tiene muchos problemas a la hora de mantener el código:
En la gestión de cada acción o de las transiciones, tendrías que discriminar la acción a realizar en función del estado interno. Creo que no existe ninguna forma de verificar que lo que si el tipo/interfaz dice que se puede realizar una determinada acción o transición, realmente sea así y al final necesites hacer exactamente los mismos tests que si no tuvieras tipado.
Posibilidades para gestionar las ramas de ejecución según la variable de estado dentro de cada método:
- Hacer múltiples if-else según el estado. Si añades un nuevo estado, no hay nada que te obligue a implementar esa rama. Si lanzas un else genérico que no haga nada o lance un error, es una comprobación en ejecución. Si quitas un estado, tampoco te avisa directamente de que el estado no existe, tendrías que borrar el identificador del estado primero. Tampoco creo que haya forma de vincular estáticamente la existencia de un estado con la existencia de su identificador (lo cual puede derivar en identificadores que no se usen o en ramas de estados que ya no existen).
- Hacer un switch soluciona algunos problemas, porque se puede obligar a que existan los 'case' para todos los identificadores poniendo en el caso default un check con un tipo 'never'. Pero mantiene el resto de problemas de if-else. Añade también otro problema de error humano, y es el olvido de break/return de algún caso.
En ambos casos, hay que tener en cuenta que tanto para añadir comportamiento como para modificarlo, hay que tocar código existente (sí, añadir un case o un if-else es modificar código existente). Con esto básicamente te estás saltando el principio de Open-Closed. No quiere decir que la solución no vaya a funcionar, sino que probablemente más pronto que tarde va a dar problemas de mantenibilidad por errores humanos. Por lo que la mejor idea que se me ocurre es hacer la implementación de cada estado por separado y añadirla al SuperState, de modo que con polimorfismo, se llame simplemente al método del estado actual y no haya que hacer esta comprobación con identificadores.
El problema es que aún así, hay que gestionar los casos en los que no exista la acción o el cambio de estado (lanzando un error, no haciendo nada...) para cada estado, teniendo también en cuenta que esto puede cambiar a futuro y quieras que métodos que no debían funcionar funcionen y al revés, y no haya forma estática de comprobar que efectivamente estén implementadas. Esto dice a gritos que estamos incumpliendo el Principio de sustitución de Liskov (LSP). O sea, que tenemos el problema que básicamente te he descrito. Si se puede solucionar de alguna manera, no se me ocurre. Si a ti se te ocurre, te invito a compartirlo.
Estoy implementando una solución propia para la Máquina de Estados en TypeScript basado en lo que BettaTech menciona en el vídeo, y que gestiona la invalidación de instancias de estados anteriores. Si te interesa, dímelo y pongo aquí el repo cuando la haya terminado.
Y perdón por la parrafada. Estas cosas son más complejas de lo que a veces parecen xD
¡Gran video! Como aporte, con Rust se puede usar PhantomData para manejar estados, lo cual permite que una estructura (las "clases" de Rust) implemente métodos distintos dependiendo de su estado, ya que para Rust son tipos diferentes.
Lo mejor de todo es que en este lenguaje el tamaño de las estructuras es igual a la suma del tamaño de sus atributos, por lo que si nuestros estados son estructuras sin atributos, da como resultado que el uso de estados es una abstracción a costo 0.
Increible!! Me encantaria poder trabajar con Rust 😂
Gracias!! Justo estoy estudiando estos temas en la universidad y ahora se me han aclarado algunas dudas que tenía
Con el patrón state puedes encapsular la implementación interna de las clases en una interfaz execute siempre que el lenguaje permita polimorfismo. ¿No? Y así te evitas que se conozca la implementación de todo quisqui. Quizá aquí habla un programador java de más, ¿Eh?
me mato el meme de de la función sort() de javascript jajajajajaja
Excelente contenido me gustó mucho y aprendí algo nuevo gracias nunca parés
Una pregunta BettaTech. Quiero ser backend y sabes que para uno resolver problemas en un lenguaje específico, se necesita aprender estructura de datos y algoritmos, pero ¿puedo aprender las funciones que traen los lenguajes para esas estructuras de datos o aprenderla tal y como hacen los tutoriales?
Python y ruby también hay un paso previo antes la ejecución de un binario…
Cómo bien se ve en el minuto 1:11, python no es un lenguaje de tipado estático, lo que según leí, lo inhabilita para hacer TyDD (type-driven development). Sin embargo me pregunto si no se podrá hacer algo parecido de todas formas con bibliotecas como pytyped o pytype. 🤔
Buen video, este consepto se usa en flutter con BLoC para manejar el estado de la aplicacion.
Ostias, no lo sabia!
hola! excelente video! consulta, en el minuto @11:39, se muestra la definicion de la clase websocket con el atributo #state, que hace el numeral o gato antes de un atributo en typescript?
En Javascript sirve para denotar miembros privados (en TypeScript se pueden denotar de ésa manera o añadiendo el modificador "private" antes).
Gracias Betta, fue una explicación muy buena .
Gracias a ti por ver el video!!
El Type Driven Design no es más que el pateo de diseño Prototype. No es una cosa, Uni testing cubre los types por eso Type Drive Design no es un tema…
Me ha encantado el video!! Super interesante y muy útil. Un 10!!
Muchisimas gracias!!!!
moy lendo el filtro CTR, la verdá
Yo me negaba a aprender typescript y ahora no puedo programar sin el xD
que video tan espectacular, gracias
La parte que no entiendo es porque esto nos hace tener menos test? ahora tenemos 2 componentes que probar, y ademas tenemos que modificar la logica que use a este sockets para que tenga que gestionar estos dos tipos de objetos a menos que usemos un orquestador de "estados" que gestionaria estos dos tipos de objetos (ya que ahora cada objeto es la representación de un estado) y tendriamos que hacerle test tambien enfocado en comprobar que el orquestador funcione de manera correcta, entonces no se si para este ejemplo sea el mejor de los casos, ya que si, se fuerza al flujo a que los metodos esten mas segregados aun (un objeto se encarga de gestionar la creacion y otro la conexion) pero pues a la larga estamos es escalando la complejidad y quien use esto, debe incluir el test del manejo de estos "estados"
La cosa está en que te ahorras todos los test tipo: "Debe dar error si se intenta emitir un evento sin haber conectado", porque de eso se encarga el sistema de tipos. Directamente no te compila porque es imposible ese estado.
Ningun test podra testear que eso sucede (que se emite un error) porque es un estado imposible. No digo que elimine TODOS los test, pero si los que son inútiles (nunca deberias poder hacer eso que estás testeando para que no pase)
Muy buen vídeo Martín! Pero no seas tan duro contigo mismo y enciende el aire acondicionado hombre que estás chorreando...😘😂
Sabes lo peor? Estaba encendido xdddd
me recuerda a value object pero mas completo
"ConnectedSocket"... *Se va el internet*
Gracias 🇲🇽
No he entendido nada pero espero poder entenderlo algun dia ❤
Muy bien video
Excelente, que calidad. Cada video es mejor que el anterior en cuanto a calidad de producción... Y los conocimientos bueno tu sabes qu eso es variado pero al final no hay desperdicio en ello!
👍
Hacer cinco céntimos es un catalanismo que no creo que tenga traducción al castellano estándar y no sé qué entenderán los del resto del territorio español
Jajaja ni me di cuenta 😅
Suscrito de una 😂
TypeScript destruye a los programadores novatos y es inútil para los
Programadores expertos
...pues yo soy experto y me es bastante útil, no entiendo por qué ésa aseveración
Tampoco sé si entiendo por qué "destruye a los programadores novatos", no me parece que sea más complejo que Java, que muchas veces es el primer lenguaje que se les enseña a los novatos.
y porque no en java?¿ es lo mismo, o en C#¿