Método de encadenamiento - ¿por qué es una buena práctica, o no?

Solo mis 2 centavos;

El encadenamiento de métodos hace que la depuración sea complicada: - No se puede poner el punto de interrupción en un punto conciso para que pueda pausar el programa exactamente donde lo desee - Si uno de estos métodos lanza una excepción, y obtiene un número de línea, no tiene idea de qué método en la "cadena" causó el problema.

Creo que generalmente es una buena práctica escribir siempre líneas muy cortas y concisas. Cada línea solo debe hacer una llamada al método. Prefiera más líneas a más largas alinear.

EDIT: comment menciona que el encadenamiento de métodos y los saltos de línea están separados. Eso es verdad. Sin embargo, dependiendo del depurador, puede o no ser posible colocar un punto de interrupción en el medio de una instrucción. Incluso si puede, el uso de líneas separadas con variables intermedias le da mucha más flexibilidad y un montón de valores que puede examinar en la ventana de Vigilancia que ayuda al proceso de depuración.

Personalmente, prefiero métodos de encadenamiento que solo actúan sobre el objeto original, por ejemplo, establecer múltiples propiedades o llamar a métodos de tipo utilidad.

foo.setHeight(100).setWidth(50).setColor('#ffffff');
foo.moveTo(100,100).highlight();

No lo uso cuando uno o más de los métodos encadenados devuelven cualquier objeto que no sea foo en mi ejemplo. Si bien sintácticamente puede encadenar cualquier cosa, siempre y cuando esté utilizando la API correcta para ese objeto en la cadena, cambiar objetos en mi humilde opinión hace que las cosas sean menos legibles y puede ser realmente confuso si las API para los diferentes los objetos tienen similitudes. Si haces alguna llamada método muy común al final (.toString(), .print(), lo que sea) ¿sobre qué objeto estás actuando en última instancia? Alguien casualmente leyendo el código no puede detectar que sería una forma implícita objeto devuelto en la cadena, en lugar de la referencia original.

Encadenar diferentes objetos también puede conducir a errores nulos inesperados. En mis ejemplos, suponiendo que foo es válido, todas las llamadas al método son "seguras" (por ejemplo, válidas para foo). En el Ejemplo de OP:

participant.getSchedule('monday').saveTo('monnday.file')

...no hay garantía (como un desarrollador externo mirando el código) de que getSchedule realmente devolverá un objeto de programación válido, no nulo. Además, depurar este estilo de código es a menudo mucho más difícil ya que muchos IDE no evaluarán la llamada al método en el momento de la depuración como un objeto que puede inspeccionar. IMO, cada vez que necesite un objeto para inspeccionar con fines de depuración, prefiero tenerlo en una variable explícita.

Martin Fowler tiene una buena discusión aquí:

Método De Encadenamiento

Cuándo usarlo

Método de encadenamiento puede agregar una gran cantidad a la legibilidad de un DSL interno y como resultado se ha convertido casi en un synonum para DSL internos en algunos mente. Método de encadenamiento es mejor, sin embargo, cuando se utiliza en conjunción con otras combinaciones de funciones.

Método de encadenamiento es particularmente eficaz con gramáticas como parent::= (esto / aquello)*. El uso de diferentes métodos proporciona forma legible de viendo qué argumento viene después. Del mismo modo argumentos opcionales pueden ser se salta fácilmente con el Método Encadenar. Una lista de cláusulas obligatorias, como padre:: = el primer segundo no funciona tan bien con la forma básica, aunque puede ser apoyado bien por uso de interfaces progresivas. La mayoría de el tiempo que preferiría Función Anidada para ese caso.

El mayor problema para el Método El encadenamiento es el problema del acabado. Mientras que hay soluciones, por lo general si este es mejor usng una Función Anidada. Anidar La función es también una mejor opción si te estás metiendo en un lío con Variables de Contexto.

En mi opinión, el encadenamiento método es un poco de una novedad. Claro, se ve bien, pero no veo ninguna ventaja real en él.

Cómo es:

someList.addObject("str1").addObject("str2").addObject("str3")

Mejor que:

someList.addObject("str1")
someList.addObject("str2")
someList.addObject("str3")

La excepción puede ser cuando addObject() devuelve un nuevo objeto, en cuyo caso el código unchained puede ser un poco más engorroso como:

someList = someList.addObject("str1")
someList = someList.addObject("str2")
someList = someList.addObject("str3")

Es peligroso porque puede estar dependiendo de más objetos de lo esperado, como entonces su llamada devuelve una instancia de otra clase:

Daré un ejemplo:

FoodStore es un objeto que se compone de muchas tiendas de alimentos que usted posee. foodstore.getLocalStore () devuelve un objeto que contiene información en el almacén más cercano al parámetro. getPriceforProduct (cualquier cosa) es un método de ese objeto.

Así que cuando llamas Tienda de alimentos.getLocalStore(parámetros).getPriceforProduct (cualquier cosa)

No solo depende de FoodStore, sino también de LocalStore.

Si getPriceforProduct(cualquier cosa) cambia, necesita cambiar no solo FoodStore sino también la clase que llamó al método encadenado.

Siempre debe apuntar a un acoplamiento suelto entre las clases.

Dicho esto, personalmente me gusta encadenarlos al programar Ruby.

Beneficios del Encadenamiento
es decir, donde me gusta usarlo

Un beneficio del encadenamiento que no vi mencionado fue la capacidad de usarlo durante la iniciación variable, o al pasar un nuevo objeto a un método, no estoy seguro de si esto es una mala práctica o no.

Sé que este es un ejemplo artificial, pero digamos que tiene las siguientes clases

Public Class Location
   Private _x As Integer = 15
   Private _y As Integer = 421513

   Public Function X() As Integer
      Return _x
   End Function
   Public Function X(ByVal value As Integer) As Location
      _x = value
      Return Me
   End Function

   Public Function Y() As Integer
      Return _y
   End Function
   Public Function Y(ByVal value As Integer) As Location
      _y = value
      Return Me
   End Function

   Public Overrides Function toString() As String
      Return String.Format("{0},{1}", _x, _y)
   End Function
End Class

Public Class HomeLocation
   Inherits Location

   Public Overrides Function toString() As String
      Return String.Format("Home Is at: {0},{1}", X(), Y())
   End Function
End Class

Y decir que no tiene acceso a la clase base, o decir que los valores predeterminados son dinámicos, basados en el tiempo, etc. Sí usted podría instanciar entonces, luego cambiar los valores, pero eso puede volverse engorroso, especialmente si solo está pasando los valores a un método:

  Dim loc As New HomeLocation()
  loc.X(1337)
  PrintLocation(loc)

Pero esto no es mucho más fácil de leer:

  PrintLocation(New HomeLocation().X(1337))

O, ¿qué pasa con un miembro de la clase?

Public Class Dummy
   Private _locA As New Location()
   Public Sub New()
      _locA.X(1337)
   End Sub
End Class

Vs

Public Class Dummy
   Private _locC As Location = New Location().X(1337)
End Class

Así es como he estado usando el encadenamiento, y por lo general mis métodos son solo para la configuración, por lo que son solo 2 líneas de largo, establecer un valor, entonces Return Me. Para nosotros ha limpiado enormes líneas muy difíciles de leer y entiende el código en una línea que se lea como una oración. algo así como

New Dealer.CarPicker().Subaru.WRX.SixSpeed.TurboCharged.BlueExterior.GrayInterior.Leather.HeatedSeats

Vs Algo como

New Dealer.CarPicker(Dealer.CarPicker.Makes.Subaru
                   , Dealer.CarPicker.Models.WRX
                   , Dealer.CarPicker.Transmissions.SixSpeed
                   , Dealer.CarPicker.Engine.Options.TurboCharged
                   , Dealer.CarPicker.Exterior.Color.Blue
                   , Dealer.CarPicker.Interior.Color.Gray
                   , Dealer.CarPicker.Interior.Options.Leather
                   , Dealer.CarPicker.Interior.Seats.Heated)

Detrimento Del Encadenamiento
es decir, donde no me gusta usarlo

No utilizo el encadenamiento cuando hay muchos parámetros para pasar a las rutinas, principalmente porque las líneas se vuelven muy largas, y como el OP mencionó puede ser confuso cuando estás llamando rutinas a otras clases para pasar a uno de los métodos de encadenamiento.

También está el preocupación de que una rutina devolvería datos no válidos, por lo que hasta ahora solo he utilizado encadenamiento cuando estoy devolviendo la misma instancia que se llama. Como se señaló, si encadenas entre clases, haces que debugear sea más difícil (¿cuál devuelve null?) y puede aumentar el acoplamiento de dependencias entre clases.

Conclusión

Como todo en la vida, y la programación, el encadenamiento no es ni bueno, ni malo si se puede evitar lo malo, entonces el encadenamiento puede ser un gran beneficio.

Trato de sigue estas reglas.

1. Trate de no encadenar entre clases
2. Hacer rutinas específicamente para encadenamiento
3. Hacer solo UNA cosa en un encadenamiento rutina
4. Úsalo cuando mejore la legibilidad
5. Úsalo cuando simplifique el código

El encadenamiento de métodos permite diseñar DSLs avanzados directamente en Java. En esencia, puede modelar al menos estos tipos de reglas DSL:

1. SINGLE-WORD
2. PARAMETERISED-WORD parameter
3. WORD1 [ OPTIONAL-WORD]
4. WORD2 { WORD-CHOICE-A | WORD-CHOICE-B }
5. WORD3 [ , WORD3 ... ]

Estas reglas se pueden implementar usando estas interfaces

// Initial interface, entry point of the DSL
interface Start {
  End singleWord();
  End parameterisedWord(String parameter);
  Intermediate1 word1();
  Intermediate2 word2();
  Intermediate3 word3();
}

// Terminating interface, might also contain methods like execute();
interface End {}

// Intermediate DSL "step" extending the interface that is returned
// by optionalWord(), to make that method "optional"
interface Intermediate1 extends End {
  End optionalWord();
}

// Intermediate DSL "step" providing several choices (similar to Start)
interface Intermediate2 {
  End wordChoiceA();
  End wordChoiceB();
}

// Intermediate interface returning itself on word3(), in order to allow for
// repetitions. Repetitions can be ended any time because this interface
// extends End
interface Intermediate3 extends End {
  Intermediate3 word3();
}

Con estas simples reglas, puedes implementar DSL complejos como SQL directamente en Java, como lo hace jOOQ, una biblioteca que he creado. Vea un ejemplo SQL bastante complejo tomado de mi blog aquí:

create().select(
    r1.ROUTINE_NAME,
    r1.SPECIFIC_NAME,
    decode()
        .when(exists(create()
            .selectOne()
            .from(PARAMETERS)
            .where(PARAMETERS.SPECIFIC_SCHEMA.equal(r1.SPECIFIC_SCHEMA))
            .and(PARAMETERS.SPECIFIC_NAME.equal(r1.SPECIFIC_NAME))
            .and(upper(PARAMETERS.PARAMETER_MODE).notEqual("IN"))),
                val("void"))
        .otherwise(r1.DATA_TYPE).as("data_type"),
    r1.NUMERIC_PRECISION,
    r1.NUMERIC_SCALE,
    r1.TYPE_UDT_NAME,
    decode().when(
    exists(
        create().selectOne()
            .from(r2)
            .where(r2.ROUTINE_SCHEMA.equal(getSchemaName()))
            .and(r2.ROUTINE_NAME.equal(r1.ROUTINE_NAME))
            .and(r2.SPECIFIC_NAME.notEqual(r1.SPECIFIC_NAME))),
        create().select(count())
            .from(r2)
            .where(r2.ROUTINE_SCHEMA.equal(getSchemaName()))
            .and(r2.ROUTINE_NAME.equal(r1.ROUTINE_NAME))
            .and(r2.SPECIFIC_NAME.lessOrEqual(r1.SPECIFIC_NAME)).asField())
    .as("overload"))
.from(r1)
.where(r1.ROUTINE_SCHEMA.equal(getSchemaName()))
.orderBy(r1.ROUTINE_NAME.asc())
.fetch()

Otro buen ejemplo es jRTF, un pequeño DSL diseñado para cerarar documentos RTF directamente en Java. Un ejemplo:

rtf()
  .header(
    color( 0xff, 0, 0 ).at( 0 ),
    color( 0, 0xff, 0 ).at( 1 ),
    color( 0, 0, 0xff ).at( 2 ),
    font( "Calibri" ).at( 0 ) )
  .section(
        p( font( 1, "Second paragraph" ) ),
        p( color( 1, "green" ) )
  )
).out( out );

Esto parece un poco subjetivo.

Método de encadenamiento no es soemthing que es inherentemente malo o bueno imo.

La legibilidad es lo más importante.

(También considere que tener un gran número de métodos encadenados hará que las cosas sean muy frágiles si algo cambia)

Muchos utilizan el encadenamiento de métodos como una forma de conveniencia en lugar de tener en cuenta cualquier preocupación de legibilidad. El encadenamiento de métodos es aceptable si implica realizar la misma acción en el mismo objeto, pero solo si realmente mejora la legibilidad, y no solo para escribir menos código.

Desafortunadamente muchos usan encadenamiento de métodos según los ejemplos dados en la pregunta. Mientras que pueden todavía ser legibles, desafortunadamente están causando un alto acoplamiento entre múltiples clases, así que no es deseable.

Método de encadenamiento puede ser simplemente una novedad para la mayoría de los casos, pero creo que tiene su lugar. Un ejemplo se puede encontrar en El uso activo del Registro de CodeIgniter :

$this->db->select('something')->from('table')->where('id', $id);

Que se ve mucho más limpio (y tiene más sentido, en mi opinión) que:

$this->db->select('something');
$this->db->from('table');
$this->db->where('id', $id);

Realmente es subjetivo, cada uno tiene su propia opinión.

El punto totalmente perdido aquí, es que el encadenamiento método permite SECO. Es un sustituto efectivo para el " con " (que está mal implementado en algunos idiomas).

A.method1().method2().method3(); // one A

A.method1();
A.method2();
A.method3(); // repeating A 3 times

Esto importa por la misma razón que DRY siempre importa; si A resulta ser un error, y estas operaciones deben realizarse en B, solo necesita actualizar en 1 lugar, no en 3.

Pragmáticamente, la ventaja es pequeña en este caso. Sin embargo, un poco menos de mecanografía, un poco más robusto (SECO), lo tomaré.

Estoy de acuerdo, por lo tanto cambié la forma en que se implementó una interfaz fluida en mi biblioteca.

Antes:

collection.orderBy("column").limit(10);

Después de:

collection = collection.orderBy("column").limit(10);

En la implementación "before" las funciones modificaron el objeto y terminaron en return this. Cambié la implementación a devuelve un nuevo objeto del mismo tipo.

Mi razonamiento para este cambio:

1. El valor devuelto no tenía nada que ver con la función, estaba puramente allí para apoyar el parte de encadenamiento, Debería haber sido una función de vacío de acuerdo con OOP.

2. El encadenamiento de métodos en las bibliotecas del sistema también lo implementa de esa manera (como linq o string):

   myText = myText.trim().toUpperCase();
   

3. El objeto original permanece intacto, lo que permite al usuario de la API decidir qué hacer con él. Permite:

   page1 = collection.limit(10);
   page2 = collection.offset(10).limit(10);
   

4. A copy implementation también se puede usar para construir objetos:

   painting = canvas.withBackground('white').withPenSize(10);
   

   Donde la función setBackground(color) cambia la instancia y devuelve nada (como se supone que debe).

5. El comportamiento de las funciones es más predecible (ver puntos 1 y 2).

6. El uso de un nombre de variable corto también puede reducir el desorden de código, sin forzar una api en el modelo.

   var p = participant; // create a reference
   p.addSchedule(events[1]);p.addSchedule(events[2]);p.setStatus('attending');p.save()
   

Conclusión:
En mi opinión, una interfaz fluida que utiliza una implementación return this está mal.

El bien:

1. Es conciso, sin embargo, le permite poner más en una sola línea elegantemente.
2. A veces se puede evitar el uso de una variable, que en ocasiones puede ser útil.
3. puede funcionar mejor.

Lo malo:

1. Está implementando retornos, esencialmente agregando funcionalidad a los métodos en objetos que no es realmente una parte de lo que esos métodos están destinados a hacer. Es devolver algo que ya tienes puramente para salvar a unos pocos byte.
2. Oculta los cambios de contexto cuando una cadena conduce a otra. Puedes obtener esto con getters, excepto que es bastante claro cuando el contexto cambia.
3. Encadenar varias líneas se ve feo, no funciona bien con sangría y puede causar cierta confusión en el manejo del operador (especialmente en idiomas con ASI).
4. Si desea comenzar a devolver algo más que sea útil para un método encadenado, potencialmente tendrá más dificultades para arreglarlo o tendrá más problemas consigo.
5. Está descargando el control a una entidad que normalmente no descargaría a puramente por conveniencia, incluso en lenguajes estrictamente escritos los errores causados por esto no siempre se pueden detectar.
6. puede funcionar peor.

General:

Un buen enfoque es no usar el encadenamiento en general hasta que surjan situaciones o módulos específicos sean particularmente adecuados para ello.

El encadenamiento puede dañar la legibilidad bastante severamente en algunos casos, especialmente cuando se pesa puntos 1 y 2.

En accasation puede ser mal utilizado, como en lugar de otro enfoque (pasar una matriz, por ejemplo) o métodos de mezcla de maneras extrañas (padre.setSomething().getChild ().setSomething().getParent().setSomething ()).

Creo que la falacia principal es pensar que este es un enfoque orientado a objetos en general, cuando de hecho es más un enfoque de programación funcional que cualquier otra cosa.

Las principales razones por las que lo uso es tanto para la legibilidad como para evitar que mi código sea inundado por variables.

Realmente no entiendo de qué están hablando los demás cuando dicen que daña la legibilidad. Es una de las formas de programación más concisas y cohesivas que he usado.

También esto:

ConvertTextToVoice.LoadText ("source.txt").ConvertToVoice (destino".wav");

Es como lo usaría normalmente. Usarlo para encadenar x número de parámetros no es como lo uso normalmente. Si quisiera poner un número x de parámetros en una llamada a un método, usaría la sintaxis params:

Public void foo (params object[] items)

Y emitir los objetos en función del tipo o simplemente utilizar una matriz de tipos de datos o colección dependiendo de su uso caso.