Hola.
Hoy vamos para hablar de mensajes
Verás por qué tener muchos mensajes y los pequeños métodos son buenos.
Contrariamente a lo que muchos desarrolladores creen.
Esta diapositiva ilustra una secuencia de diseño
Esto es válido no solo para Pharo,
pero para el diseño en cualquier lenguaje orientado a objetos.
Como sabes, los mensajes enviados son ganchos,
lugares donde podemos definir el comportamiento.
Los desarrolladores a menudo dicen que les gustan los grandes métodos porque
Son fáciles de entender.
Lees las lineas y entiendes el código.
Pero en esta sesión te mostraré
que esto no es tan bueno.
En general, Los grandes métodos significan un mal diseño.
Una jerarquía de clases
y un mismo método implementado en varias clases,
es un medio de definir elecciones.
Si tomo una clase de grasa con muchas operaciones,
y tengo que elegir una operación según el estado,
mi código dirá:"Si estoy en este estado, Hago esta operación
"Si estoy en ese estado, Yo hago esa operación ".
Tendrás grandes códigos
con IFs por todo el lugar.
Esto significa que cuando desee agregar nuevos casos,
Tienes que modificar métodos en todas partes.
En la versión en el lado derecho,
la operación para cada caso se divide en una clase específica.
Todo lo que tienes que hacer es enviar un mensaje de operación
a un objeto para crear un FI.
El FI no necesita ser escrito por el programador
Se hace automáticamente a través del principio de polimorfismo.
En las siguientes diapositivas, te mostraré cómo mejorar un ejemplo
cambiando pequeños bits a la vez.
Aquí hay un gran método eso no es fácil de entender
y que hace muchas cosas.
Esto es lo que queremos hacer.
En una subclase,
queremos dar esta variable aquí un valor diferente
Como está configurado,
la única forma de hacer eso es crear la subclase,
luego duplique todo el código,
agregando la pequeña modificación quieres hacer
En lenguajes como Java
que usan palabras clave privadas,
si los atributos utilizado por el método son privados,
lo que acabo de hacer es imposible
Si el método usa variables de instancia que son privadas,
las subclases no pueden duplicar el código.
Pero en cualquier caso, duplicar no es una buena práctica,
porque la duplicación también copia errores.
Si tengo un error en mi versión original, Tendré un error en mis copias.
Y si modifico una copia, Tengo que modificar todas las duplicaciones.
Es trabajo extra para el desarrollador.
y debes recordar que hay varias copias
La solución real es enviar mensajes.
En un método, cuando envía un mensaje en lugar de escribir
el contenido del método correspondiente directamente en el interior,
Las subclases pueden anular el comportamiento.
Si miramos el método de la barra,
envía foo a ti mismo.
En A, foo devuelve 10,
pero las subclases puede anular este valor
y sustitúyalo por 42, por ejemplo.
Entonces, ¿cómo podemos mejorar? el código que acabas de ver
y beneficiarse de el mecanismo de herencia
sin usar duplicación
Voy a extraer esta parte aquí y envíe un mensaje en su lugar.
Se realiza mediante una función de refactorización llamado método de extracción.
Tienes herramientas para transformar este código En este código aquí.
El código que seleccioné en la diapositiva anterior
fue transferido en un nuevo método llamado ratio.
Y aquí donde se escribió el código, ahora tenemos un mensaje de envío.
Esto significa que en las subclases,
Puedo cambiar este comportamiento
Cambie por completo
o recordar el comportamiento de la superclase y hacer una modificación.
Eso es lo que estoy haciendo aquí.
Envío un mensaje de relación a super
para ejecutar el código tal como es en la superclase,
y agrego 10, que es mi objetivo.
Otro método posible es extraer esta parte aquí,
para que las subclases puede cambiar este comportamiento
Extraigo esta pieza de código
En un metodo especifico.
Y en el método primario, Envío un mensaje
En este caso,
la clase que queremos una variable de instancia está en hardcode.
Esto significa que si las subclases quieres cambiar esta clase,
para obtener potencialmente una subclase UINode,
tendrá que duplicar todo el método
Aquí podemos usar el mismo proceso
y extraiga la clase en un método,
para que las subclases puede cambiar la variable de instancia.
Eso es lo que estoy haciendo aquí.
Extraigo la parte que me interesa en un metodo,
y envío un mensaje
Enviar un mensaje habilita las subclases para cambiar el comportamiento
Como dije antes, ciertos programadores
No estás de acuerdo con este enfoque.
Les resulta difícil leer muchos pequeños métodos dispersos.
Prefieren leer un gran método linea por linea.
Esta no es una buena práctica, porque leer código línea por línea
no funcionará si la aplicación es muy grande
No puedes leer línea por línea. y entiende lo que está pasando.
Aquí es donde las abstracciones son útiles y extrayendo trozos de comportamiento
o expresiones de métodos tiene sentido.
Puedes leer un método a nivel mundial. sin comprender todos los detalles.
Así que los pequeños métodos son buenos, deberías usarlos en todas partes.
Vamos a seguir
Aquí vemos que el valor 55 aparece en el código rígido
en el codigo de metodo
Esto significa que las subclases No se puede cambiar a 100, por ejemplo.
Entonces extraeremos este valor como hicimos anteriormente,
y ponerlo en un método separado para que las subclases pueden cambiar el valor.
Otra ventaja es que anteriormente
el valor 55 se escribió aquí.
Ahora se llama self averageRatio.
Esto significa que reemplazamos un valor numérico por un nombre,
y ahora sé lo que el valor 55 corresponde a.
Sé que significa AverageRatio y cuando leo el código, entiendo.
Entonces, teniendo muchos pequeños métodos Ayuda a leer el código.
Crear un método AverageRatio para regresar 55
habilita todas las subclases para cambiar valores
¿Pero cómo podemos dejar que los usuarios de clase ¿Cambiar su valor también?
Lo que podemos hacer,
es usar una variable de instancia.
El método AverageRatio usado en la diapositiva anterior
devolverá el valor de la variable de instancia,
si contiene un valor De lo contrario, devuelve el valor predeterminado.
El valor predeterminado era 55.
Y los usuarios de un objeto de nodo
puede programar cualquier valor que les guste dentro.
Con este diseño,
las subclases pueden anular el defaultAverageRatio
y cambia el valor.
Y los usuarios de clase pueden establecer un valor Ejecutando el programa.
Se llama programación orientada a gruyere.
Un programa orientado a objetos, un método WIN,
contiene agujeros llamados ganchos,
que se puede rellenar con subclases.
Como conclusión,
el código puede ser reutilizado y refinado en subclases.
Cada vez que enviamos un mensaje,
las subclases pueden cambiar el comportamiento de la superclase:
Refiéralo o cámbialo por completo.
Los pequeños métodos son excelentes porque dan nombres a trozos de expresiones,
y porque dan subclases La libertad de cambiar el comportamiento.