Hay un aspecto de la coincidencia de patrones que no entiendo.
En la documentación de la coincidencia de patrones, muestran un ejemplo como:
https://docs.scala-lang.org/tour/pattern-matching.html
abstract class Notification case class Email(sender: String, title: String, body: String) extends Notification case class SMS(caller: String, message: String) extends Notification case class VoiceRecording(contactName: String, link: String) extends Notification def showNotification(notification: Notification): String = { notification match { case Email(sender, title, _) => s"You got an email from $sender with title: $title" case SMS(number, message) => s"You got an SMS from $number! Message: $message" case VoiceRecording(name, link) => s"You received a Voice Recording from $name! Click the link to hear it: $link" } } val someSms = SMS("12345", "Are you there?") val someVoiceRecording = VoiceRecording("Tom", "voicerecording.org/id/123")Que podría ser algo recodificado en Java, como:
Notification notification = /* Init a notification instance */ if(notification instanceof Email) { Email currentEmail = (Email) notification; currentEmail.doSomething(); } else if (notification instanceof SMS) { SMS currentSMS = (SMS) notification; currentSMS.doSomething(); } else if { /* ... */ }La coincidencia de patrones parece verse muy positivamente, pero por el contrario, el equivalente de Java se ve como un "olor de código" o un mal patrón.
Según tengo entendido, están haciendo lo mismo y tal vez técnicamente también, solo está oculto para la coincidencia de patrones de Scala.
Sin embargo, tal doble rasero no pasaría desapercibido, así que supongo que hay algo mal con mi comprensión.
Bajo el capó, la coincidencia de patrones de Scala a menudo se reduce a un código que es exactamente como el código Java if (notification instanceof Email) { ... } else if (notification instanceof SMS) .
El ejemplo particular que das, de una abstract class Notification que no está sealed , es uno en el que el código Scala no es mejor (excepto quizás expresando la intención general más claramente) que el árbol if / instanceof .
Esto se debe a que el principal beneficio de la coincidencia de patrones es la posibilidad de verificar la exhaustividad. Con el enfoque if / instanceof y el ejemplo de coincidencia de patrones que presenta, no recibirá una alerta de que no ha manejado todos los casos (por ejemplo, dejó el caso de VoiceRecording ).
Al hacer que la Notification se sealed (por ejemplo, sealed abstract class Notification ), el compilador de Scala se asegurará de que ningún código Scala en otros archivos (técnicamente, unidades de compilación, que son para todos los efectos y propósitos archivos) pueda extender la Notification ; dado que ahora conoce todas las Notification posibles, puede generar un error del compilador si pierde un caso. No hay una forma confiable de hacer esto en el if / instanceof porque ese es un nivel más bajo de abstracción.
El "olor" ha sido histórico. El diseño orientado a objetos sugiere que debe permitir que la jerarquía de tipos envíe su llamada de método al subtipo apropiado, en lugar de buscar instancias reales en el sitio de la llamada. Hubo algunos malos diseños relacionados con el uso excesivo de la herencia, lo que condujo a tal instanceof de uso. La instanceof de uso no era lo malo, pero insinuaba que la jerarquía de tipos posiblemente era mala.
Por otro lado, Java 17 ahora también tiene la coincidencia de patrones de Scala (como una función de vista previa, que pronto se finalizará), por lo que realmente no se puede decir que el uso de instanceof sea algo malo en Java.