2008-09-29 45 views
8

Me encanta la filosofía de los métodos de encadenamiento, como jQuery enfasis en su biblioteca. Lo encontré bastante elegante y claro.Ventajas y desventajas de los métodos encadenables?

Siendo principalmente desarrollador de Java, siempre me he preguntado por qué esta práctica no se usaba más en este lenguaje. Por ejemplo, la interfaz de Colección no fue diseñada de esa manera (para agregar/eliminar métodos), y la encontré bastante triste.

¿Hay contras reales contra esta práctica o es simplemente algo que no tiene suficiente "atractivo sexual" antes?

Respuesta

0

Martin Fowler discute este tema como 'interfaces fluidas' en http://www.martinfowler.com/bliki/FluentInterface.html. Un problema principal es que las interfaces fluidas están diseñadas para humanos, por lo tanto, marcos como Spring no son capaces de entenderlos. Simplificando el uso de una interfaz fluida proporciona mantenimiento en un sentido (legibilidad) pero pierde capacidad de mantenimiento en otro (flexibilidad).

1

Me gusta mucho este enfoque también. El único inconveniente que se me ocurre es que a veces parece un poco incómodo "devolver esto" al final de cada método. Para JQuery, por ejemplo, es un poco incómodo permitir complementos, porque tienes que decir "asegúrate de no olvidar tus devoluciones". pero no hay una buena manera de atraparlo en tiempo de compilación.

+0

sería bueno si Java tuviera un pragma que dijera 'devuelve esto si no se especificó ningún otro valor de retorno'? O más probablemente una advertencia del compilador. –

1

El único problema es que pierde el tipo de devolución, por lo que el encadenamiento es bueno para operaciones que hacen cosas, pero no es bueno para operaciones que calculan cosas.

Otro problema es que con el encadenamiento, el compilador no puede determinar fácilmente las llamadas a funciones triviales para la alineación. Pero como dije si su encadenamiento hace operaciones, y no cálculos, entonces es más probable que el compilador no cambie nada de todos modos.

0

JavaScript es (más o menos) un lenguaje funcional, con funciones como ciudadanos de primera clase.
Añadiendo/quitando métodos a objetos, pasando funciones como parámetros, todo esto es natural para este lenguaje.

Por otro lado, Java es estrictamente OO, una función no puede existir fuera de una clase. Usar herencia, composición e interfaces es una forma más natural para este lenguaje.

+0

Y? ¿Cuál es la relación entre OO/concepto funcional y la forma de escribir llamada de método? ¿El paradigma realmente impacta en el uso de a.b(). C() en lugar de x = a.b(); x.c()? No lo creo. – gizmo

+0

Vaya, disculpe, ejemplo equivocado. Yo quería escribir a.b(); a.c() por supuesto. – gizmo

+0

Ah, pensé en encadenar en el sentido de anular una función, y luego llamar a la función anterior al final de la nueva, como cuando se burbujean eventos. Encadenamiento como usted describe es de hecho posible en Java (y bastante común), siempre que las funciones devuelvan el objeto adecuado. – PhiLho

3

IMO es doloroso depurar ya que tiende a no tener variables intermedias para la inspección.

+0

Por lo que yo sé, todos los IDE actuales proporcionan funciones de entrada/salida para facilitar la depuración del método encadenable, así como la llamada al método utilizada como parámetros. – gizmo

0

Los métodos encadenables son otra gran herramienta en nuestra bolsa de herramientas de diseño. Solo asegúrate de no toparte con el problema común del diseño "Tengo un martillo, por lo tanto, cada problema es un clavo".

Todos los problemas de diseño no se resuelven con métodos encadenables. A veces ayuda a que una interfaz sea más fácil de usar (es decir, el problema de recopilación que mencionó). A veces no es así. El truco es averiguar qué caso aplica.

2

Hay un problema común con los métodos encadenables y la herencia. Supongamos que tiene una clase C cuyos métodos F1(), F2(), etc. devuelven una C. Cuando obtiene la clase D de C, quiere que los métodos F1, F2, etc. devuelvan una D para que los métodos encadenables de D puedan ser llamado en cualquier parte de la cadena.

+0

En C++, esto generalmente se resuelve con CRTP: http://en.wikipedia.org/wiki/Curiously_Recurring_Template_Pattern –

+0

Es cierto que, lamentablemente, los genéricos .NET no permiten que se utilicen parámetros de plantilla en las especificaciones de clase base para una clase genérica. Eric Lippert tiene una buena explicación en su blog (http://blogs.msdn.com/ericlipper) por qué esta restricción es inevitable en la implementación .NET de los genéricos. – LBushkin

+0

Si C# siempre admite tipos de retorno covariantes, esto puede ser un problema menor. Mientras tanto, puede usar la nueva palabra clave para ocultar los métodos básicos y reemplazarlos por versiones que usen el tipo de devolución apropiado. Sugeriría llamar a la clase base en estos casos para evitar la duplicación de código. – LBushkin

Cuestiones relacionadas