Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


Android Polimorfismo: Anti-Patrón?

Estoy leyendo el libro "Programación de Android" de O'Reilly, y estoy tratando de envolver mi cabeza alrededor de la sección "Anulaciones y devoluciones de llamada" que comienza en la página 99. Usan esto como un ejemplo de buen código:

public class MyModel { public MyModel(TextView textBox) { textBox.addTextChangedListener( new TextWatcher() { public void afterTextChanged(Editable s) { handleTextChange(s); } // ... } void handleTextChange(Editable s) { // do something with s, the changed text. } } 

Y más tarde llamar a esto un anti-patrón debido a la falta de extensibilidad de encapsulación:

 public class MyModel implements TextWatcher { public MyModel(TextView textBox) { textBox.addTextChangedListener(this); } public void afterTextChanged(Editable s) { handleTextChange(s); } // ... void handleTextChange(Editable s) { // do something with s, the changed text. } } 

No veo la diferencia funcional entre los dos, aparte de la segunda es mucho más legible. Ambos toman un TextView, e implementan una función de controlador para anular. ¿No sería tan fácil extender el segundo con algo como esto?

 public class AnotherModel extends MyModel { @Override void handleTextChange(Editable s) { // another implementation } } 

2 Solutions collect form web for “Android Polimorfismo: Anti-Patrón?”

Un anti-patrón debido a la falta de extensibilidad

Extensibilidad-sabio, son similares en que ambos acercamientos permiten que una subclase modifique fácilmente el TextChangeListener existente TextChangeListener handleTextChange ; Pero son diferentes en que la única aproximación # 2 también facilita que una subclase agregue un nuevo TextChangeListener sin modificar el existente (heredado).

Incluso si la superclase usa el enfoque # 1, la subclase podría agregar un nuevo TextChangeListener usando el método # 2; Pero si estamos hablando del patrón para usar en general, entonces un uso consistente del enfoque # 2 proporcionará más extensibilidad que un uso consistente del enfoque # 1.

No me gustaría la segunda forma, ya que la clase implementa una interfaz como un truco, no porque la clase naturalmente es un subtipo de la interfaz.

La segunda forma puede ser manejable para casos simples, por lo que está bien a menos que se vuelva demasiado desordenado.

En Java 8, podemos utilizar el primer formulario en una mejor sintaxis:

  textBox.addTextChangedListener(this#handleTextChange); // method reference 
FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.