Este documento compara Scala y Java, destacando las similitudes y diferencias entre los dos lenguajes. Explica que ambos son orientados a objetos pero Scala también admite programación funcional. Luego describe algunas características específicas de cada lenguaje como el uso de objetos inmutables en Scala versus la mutabilidad en Java, y el paso implícito de valores en Scala frente al paso explícito en Java. Finalmente, aborda temas como el uso de estructuras funcionales para organizar el código en Scala y patrones de diseño

1. FROM JAVA TO SCALA
SIN MORIR EN EL
INTENTO

2. Álvaro Fidalgo Morán
Github->https://github.com/alvarofidalgo
twitter->@dmj200

3. ¿En qué se parecen Scala y Java?

4. Scala Java
Orientación a Objetos y Programación
Funcional

5. Scala Java
Orientación a Objetos y Programación
Funcional
Orientación a Objetos y tiene Lambdas

6. Scala Java
Orientación a Objetos y Programación
Funcional
Orientación a Objetos y tiene Lambdas
Trabajaremos con Objetos inmutables

7. Scala Java
Orientación a Objetos y Programación
Funcional
Orientación a Objetos y tiene Lambdas
Trabajaremos con Objetos inmutables Se usan y “abusa” de la mutabilidad de objetos

8. Scala Java
Orientación a Objetos y Programación
Funcional
Orientación a Objetos y tiene Lambdas
Trabajaremos con Objetos inmutables Se usan y “abusa” de la mutabilidad de objetos
Hay que evitar los efectos de Lado

9. Scala Java
Orientación a Objetos y Programación
Funcional
Orientación a Objetos y tiene Lambdas
Trabajaremos con Objetos inmutables Se usan y “abusa” de la mutabilidad de objetos
Hay que evitar los efectos de Lado Es muy común modificar estados internos

10. Scala Java
Orientación a Objetos y Programación
Funcional
Orientación a Objetos y tiene Lambdas
Trabajaremos con Objetos inmutables Se usan y “abusa” de la mutabilidad de objetos
Hay que evitar los efectos de Lado Es muy común modificar estados internos
Se trabaja con Valores de forma implícita

11. Scala Java
Orientación a Objetos y Programación
Funcional
Orientación a Objetos y tiene Lambdas
Trabajaremos con Objetos inmutables Se usan y “abusa” de la mutabilidad de objetos
Hay que evitar los efectos de Lado Es muy común modificar estados internos
Se trabaja con Valores de forma implícita Todos los valores se pasan de forma explícita

12. Scala Java
Orientación a Objetos y Programación
Funcional
Orientación a Objetos y tiene Lambdas
Trabajaremos con Objetos inmutables Se usan y “abusa” de la mutabilidad de objetos
Hay que evitar los efectos de Lado Es muy común modificar estados internos
Se trabaja con Valores de forma implícita Todos los valores se pasan de forma explícita
Para “ordenar” el código se utilizan estructuras
funcionales

13. Scala Java
Orientación a Objetos y Programación
Funcional
Orientación a Objetos y tiene Lambdas
Trabajaremos con Objetos inmutables Se usan y “abusa” de la mutabilidad de objetos
Hay que evitar los efectos de Lado Es muy común modificar estados internos
Se trabaja con Valores de forma implícita Todos los valores se pasan de forma explícita
Para “ordenar” el código se utilizan estructuras
funcionales
Para “ordenar” el código se utilizan Patrones de
diseño orientados a objetos

14. Scala Java
Orientación a Objetos y Programación
Funcional
Orientación a Objetos y tiene Lambdas
Trabajaremos con Objetos inmutables Se usan y “abusa” de la mutabilidad de objetos
Hay que evitar los efectos de Lado Es muy común modificar estados internos
Se trabaja con Valores de forma implícita Todos los valores se pasan de forma explícita
Para “ordenar” el código se utilizan estructuras
funcionales
Para “ordenar” el código se utilizan Patrones de
diseño orientados a objetos
Es mejor inyectar dependencias por función

15. Scala Java
Orientación a Objetos y Programación
Funcional
Orientación a Objetos y tiene Lambdas
Trabajaremos con Objetos inmutables Se usan y “abusa” de la mutabilidad de objetos
Hay que evitar los efectos de Lado Es muy común modificar estados internos
Se trabaja con Valores de forma implícita Todos los valores se pasan de forma explícita
Para “ordenar” el código se utilizan estructuras
funcionales
Para “ordenar” el código se utilizan Patrones de
diseño orientados a objetos
Es mejor inyectar dependencias por función Se inyectan dependencias por constructor

16. RECORRIENDO LISTAS …...

17. Cuando queremos utilizar Lambdas para recorrer Streams en Java hay que crear un
Objeto del tipo Stream.
RECORRIENDO LISTAS

18. Veamos cuales son las operaciones más usadas sobre Streams
RECORRIENDO LISTAS

19. Veamos cuales son las operaciones más usadas sobre Streams
RECORRIENDO LISTAS

20. Veamos cuales son las transformaciones más usadas sobre Streams
RECORRIENDO LISTAS

21. Veamos cuales son las acciones más utilizadas
RECORRIENDO LISTAS

22. Veamos cuales son las acciones más utilizadas
RECORRIENDO LISTAS

23. Veamos cuales son las acciones más utilizadas
RECORRIENDO LISTAS

24. Veamos cuales son las acciones más utilizadas
RECORRIENDO LISTAS

25. Echemos un vistazo a Scala
RECORRIENDO LISTAS

26. Veamos las funciones de List
RECORRIENDO LISTAS

27. Veamos las funciones de Option
RECORRIENDO LISTAS

28. Veamos las funciones de Either
RECORRIENDO LISTAS

29. Veamos las funciones de Future
RECORRIENDO LISTAS

30. Veamos las funciones de Future
RECORRIENDO LISTAS

31. Veamos las funciones de Try
RECORRIENDO LISTAS

32. RECORRIENDO LISTAS

33. RECORRIENDO LISTAS
Desde luego que no , si nos fijamos en las funcione que todos comparten son de transformación Map y
FlatMap ….

34. IMPLÍCITOS

35. implícitos
VEAMOS UNOS EJEMPLOS

36. implícitos
VEAMOS UNOS EJEMPLOS

37. EVITAR INTRODUCIR EFECTOS DE LADO EN
LAMBDAS

38. EVITAR INTRODUCIR EFECTOS DE LADO EN LAMBDAS
Veamos un ejemplo claro de efecto de lado en Java

39. EVITAR INTRODUCIR EFECTOS DE LADO EN LAMBDAS
Si nos fijamos en Java 8 utilizamos el forEach pero queda un poquito más feo

40. EVITAR INTRODUCIR EFECTOS DE LADO EN LAMBDAS
Veamos el tipo de objeto que se modifica

41. EVITAR INTRODUCIR EFECTOS DE LADO EN LAMBDAS

42. EVITAR INTRODUCIR EFECTOS DE LADO EN LAMBDAS
Para resolver el mismo problema en Scala al principio se modela así .

43. EVITAR INTRODUCIR EFECTOS DE LADO EN LAMBDAS
Al final utilizando este enfoque “malo” seguiremos teniendo efectos de lado , nos estamos fijando en la
lista completa y no en la acción a realizar con cada elemento

44. EVITAR INTRODUCIR EFECTOS DE LADO EN LAMBDAS
Si eliminamos del todo el efecto de lado el código es más legible , pero aun así ¿tenemos un problema?

45. EVITAR INTRODUCIR EFECTOS DE LADO EN LAMBDAS

46. USA TRAITS NO COMO INTERFACES…..

47. Supongamos que tenemos una BBDD que se pueden insertar elementos y actualizarlos
USA TRAITS NO COMO INTERFACES

48. Una implementación para una BBDD relacional podría ser esta
USA TRAITS NO COMO INTERFACES

49. La interfaz es un contrato que hace que todas las clases que la implementen
implementen los métodos de la interfaz . Normalmente en un Lenguaje Orientado a
Objetos Utilizaremos las interfaces para clasificar objetos polimórficos del mismo tipo.
USA TRAITS NO COMO INTERFACES

50. La interfaz es un contrato que hace que todas las clases que la implementen
implementen los métodos de la interfaz . Normalmente en un Lenguaje Orientado a
Objetos Utilizaremos las interfaces para clasificar objetos polimórficos del mismo tipo.
USA TRAITS NO COMO INTERFACES
Al clasificar objetos del mismo tipo podemos llamar directamente a la interfaz sin preocuparnos de
las implementaciones.

51. USA TRAITS NO COMO INTERFACES
Al resolver el mismo problema en Scala tendemos a crear una Interfaz con un Trait

52. USA TRAITS NO COMO INTERFACES
A Implementar ese Trait de esta forma

53. USA TRAITS NO COMO INTERFACES

54. Para que no nos suceda lo anterior vamos a pensar en un Trait de forma diferente ,
vamos a verlo como un elemento que cumple unas leyes (un contrato) pero tendrá
partes implementadas por defecto y la clasificación se hará con las partes no
implementadas.
USA TRAITS NO COMO INTERFACES

55. Para que no nos suceda lo anterior vamos a pensar en un Trait de forma diferente ,
vamos a verlo como un elemento que cumple unas leyes (un contrato) pero tendrá
partes implementadas por defecto y la clasificación se hará con las partes no
implementadas.
USA TRAITS NO COMO INTERFACES

56. Vamos a modificar el trait de la siguiente manera ….
USA TRAITS NO COMO INTERFACES

57. Y ahora vamos a rellenar aquellas leyes que serán diferentes para cada Implementación
USA TRAITS NO COMO INTERFACES

58. ¿Y si queremos otra implementación?
USA TRAITS NO INTERFACES

59. Por último veremos la clase Query
USA TRAITS NO COMO INTERFACES

60. ¿ Que hemos ganado al hacer esto?
USA TRAITS NO COMO INTERFACES
Ahora cada vez que nos venga un tipo nuevo sólo tendremos que implementar aquello que lo hace
realmente diferente al resto

61. PREFERIMOS TYPE CLASSES A FACTORIAS ….

62. Una vez que hemos aprendido que a no utilizar los traits como Interfaces uno puede
decir “ Pero si eso mismo que has hecho antes se puede hacer con Java 1.8¡¡¡¡¡”
PREFERIMOS TYPE CLASSES A FACTORIAS ….

63. La implementación del HiddenElements sería esta
PREFERIMOS TYPE CLASSES A FACTORIAS ….

64. Al igual que se hizo con los traits tendremos una nueva implementación de Coffee
PREFERIMOS TYPE CLASSES A FACTORIAS ….

65. También tendremos una implementación de ingredients
PREFERIMOS TYPE CLASSES A FACTORIAS ….

66. Por último también tenemos la clase Query (Aunque para nuestro caso no nos importa)
PREFERIMOS TYPE CLASSES A FACTORIAS ….

67. En un momento dado se queremos una abstracción total de la implementación de las
tablas así que utilizaremos una factoría.
PREFERIMOS TYPE CLASSES A FACTORIAS ….

68. Por último cada vez que se quiere insertar realizaremos esto.
PREFERIMOS TYPE CLASSES A FACTORIAS ….

69. Por último cada vez que se quiere insertar realizaremos esto.
PREFERIMOS TYPE CLASSES A FACTORIAS ….

70. En la implementación de Java tenemos un efecto de Lado en tiempo de ejecución , es
decir , si el tipo de Objeto no está en la factoría el error lo detectaremos en tiempo de
ejecución .Para evitar esto en Scala podemos utilizar Type Classes
PREFERIMOS TYPE CLASSES A FACTORIAS ….

71. Para poder implementar una Type Class primero deberemos tener un Trait que será el
que marque el contrato , es decir , debemos tener las partes comunes a todos que s
implementarán en función de aquellas que son realmente diferenciadoras.
PREFERIMOS TYPE CLASSES A FACTORIAS ….

72. Debemos de tener las distintas implementaciones y estás deben poder ser llamadas en
tiempo de compilación.
PREFERIMOS TYPE CLASSES A FACTORIAS ….

73. Tendremos que disponer de una sintaxis que será como llamaremos a los métodos
PREFERIMOS TYPE CLASSES A FACTORIAS ….

74. Ahora para poder utilizar nuestra type class sólo deberemos crear una insrtancia
PREFERIMOS TYPE CLASSES A FACTORIAS ….

75. Ahora para poder utilizar nuestra type class sólo deberemos crear una insrtancia
PREFERIMOS TYPE CLASSES A FACTORIAS ….

76. Ahora todos los objetos que están en la typeClass se podrán beneficiar de esa sintaxis
PREFERIMOS TYPE CLASSES A FACTORIAS ….

77. Ahora todos los objetos que están en la typeClass se podrán beneficiar de esa sintaxis
PREFERIMOS TYPE CLASSES A FACTORIAS ….
Y los que no están implementados no se podrán beneficiar de esa sintaxis

78. PREFERIMOS TYPE CLASSES A FACTORIAS ….

79. PREFERIMOS TYPE CLASSES A FACTORIAS ….

80. PREFERIMOS TYPE CLASSES A FACTORIAS ….

81. PREFERIMOS TYPE CLASSES A FACTORIAS ….

82. PREFERIMOS TYPE CLASSES A FACTORIAS ….

83. APLICANDO CAKE PATTERN …….

84. APLICANDO CAKE PATTERN
Cuando venimos del mundo Java para inyección de dependencias se suele hacer esto..

85. APLICANDO CAKE PATTERN
Soporte y Apollo (EN GRAFÍA INGLESA)son dos interfaces

86. APLICANDO CAKE PATTERN.
Ahora supongamos que tenemos estas implementaciones de Apollo (EN GRAFÍA INGLESA)

87. APLICANDO CAKE PATTERN
.. Y estas implementaciones de Soporte

88. APLICANDO CAKE PATTERN
Ahora podriamos crear las mesas que quisiéramos..

89. APLICANDO CAKE PATTERN
En Scala se puede hacer lo mismo pero con otra sintaxis

90. APLICANDO CAKE PATTERN
Lo primero que vamos a crear es un “componente” Mesa

91. APLICANDO CAKE PATTERN
Ahora haremos el primero de los servicios que usará mesa “Apollo”

92. APLICANDO CAKE PATTERN.
Seguiremos definiendo otro servicio que utilizará la mesa ….

93. APLICANDO CAKE PATTERN
Por último crearemos la base del sistema que nos permitirá crear todas las mesas que queramos

94. APLICANDO CAKE PATTERN
Ahora con nuestras implementaciones será fácil crear sistemas

95. APLICANDO CAKE PATTERN
Ahora con nuestras implementaciones será fácil crear sistemas

96. APLICANDO CAKE PATTERN.
Ahora con nuestras implementaciones será fácil crear sistemas

97. APLICANDO CAKE PATTERN
¿Realmente hemos ganado mucho al hacer esto y no esto?

98. APLICANDO CAKE PATTERN
Al utilizar el Cake Pattern podemos introducir una serie de problemas ocultos.
Al manejar traits y no implementaciones si nos confundimos en un nombre será complejo darse cuenta

99. USAR PATRONES NO FUNCIONALES…..
Al utilizar el Cake Pattern podemos introducir una serie de problemas ocultos.
Al manejar traits y no implementaciones si nos confundimos en un nombre será complejo darse cuenta

100. USAR PATRONES NO FUNCIONALES…..
Al utilizar el Cake Pattern podemos introducir una serie de problemas ocultos.
Sin darnos cuenta estamos rompiendo la ley de Demeter

101. USAR PATRONES NO FUNCIONALES…..
Al utilizar el Cake Pattern podemos introducir una serie de problemas ocultos.
Sin darnos cuenta estamos rompiendo la ley de Demeter

102. USAR PATRONES NO FUNCIONALES…..
Al utilizar el Cake Pattern podemos introducir una serie de problemas ocultos.
Podemos hacer sistemas de mucha profundidad que a la hora de hacer cambios necesitemos mucho
tiempo para recomponer los sistemas.

103. USAR PATRONES NO FUNCIONALES…..
Al utilizar el Cake Pattern podemos introducir una serie de problemas ocultos.
Podemos hacer sistemas de mucha profundidad que a la hora de hacer cambios necesitemos mucho
tiempo para recomponer los sistemas.

104. USAR PATRONES NO FUNCIONALES…..
Al utilizar el Cake Pattern podemos introducir una serie de problemas ocultos.
Si hubiéramos utilizado la sintaxis tradicional “JAVERA” estos tres problemas nos los podíamos ahorrar
***

105. USAR PATRONES NO FUNCIONALES…..
Al utilizar el Cake Pattern podemos introducir una serie de problemas ocultos.
Si hubiéramos utilizado la sintaxis tradicional “JAVERA” estos tres problemas nos los podíamos ahorrar

106. USAR PATRONES NO FUNCIONALES…..
Al utilizar el Cake Pattern podemos introducir una serie de problemas ocultos.
Si hubiéramos utilizado la sintaxis tradicional “JAVERA” estos tres problemas nos los podíamos ahorrar

107. USAR PATRONES NO FUNCIONALES…..

108. INYECTAMOS DEPENDENCIAS CON MÓNADAS….

109. INYECTAMOS DEPENDENCIAS CON MÓNADAS
Recordemos que pasaba en nuestro Trait de acceso a BBDD …..

110. INYECTAMOS DEPENDENCIAS CON MÓNADAS
Y aunque en la cabecera no aparece en está función hay un efecto de lado de SQLException..

111. INYECTAMOS DEPENDENCIAS CON MÓNADAS
Recordamos que todas las clases de Scala compartían método Map y FlatMap , pues bién ahora vamos
a hacer uno

112. INYECTAMOS DEPENDENCIAS CON MÓNADAS
Vamos a crear un nuevo PreparedStatement “más funcional”

113. INYECTAMOS DEPENDENCIAS CON MÓNADAS
Vamos a crear un nuevo Connection “más funcional”

114. INYECTAMOS DEPENDENCIAS CON MÓNADAS
Ahora hagamos una pequeña modificación en nuestro trait de la type Class

115. INYECTAMOS DEPENDENCIAS CON MÓNADAS
Ahora vamos a ver la implementación del nuevo execute para IngredientsRepository

116. INYECTAMOS DEPENDENCIAS CON MÓNADAS
Al tener la Función FlapMap y Map podemos utilizar las for comprehension

117. INYECTAMOS DEPENDENCIAS CON MÓNADAS
Por último veamos como queda el execute del CoffeeRepository

118. CONCLUSIONES !!!!

119. ¿ ALGUNA PREGUNTA?

120. MUCHAS GRACIAS POR VUESTRA ATENCIÓN