Hace poco sugerí que se implementara un método de encadenamiento para una clase determinada en un proyecto determinado para que se pudiera mejorar la legibilidad del código. Obtuve una respuesta de "las interfaces fluidas no deberían implementarse solo por conveniencia, sino por semántica" y mi sugerencia fue rechazada. Respondí que no estaba sugiriendo una interfaz fluida sino un método de encadenamiento (ambos pueden confundirse entre sí, leer en la parte inferior) para mejorar la legibilidad y la comodidad de codificación, la sugerencia fue rechazada nuevamente.

De todos modos, esto me hizo pensar que tal vez podría incurrir en una mala práctica al devolver siempre "esto" en métodos que no se supone que devuelvan nada (p. Ej. Setters).

Mi pregunta es: ¿la aplicación de la convención anterior puede considerarse una mala práctica o abuso ?, ¿por qué ?. No creo que haya inconvenientes en el rendimiento, ¿o sí?

No

Como señala Kent Beck , el código se lee con mucha más frecuencia de lo que se escribe.

Si el encadenamiento de métodos hace que su código sea más legible, entonces use el encadenamiento de métodos.

Si, hay inconvenientes

El código que es fácil de leer es bueno, pero también tenga cuidado con lo que el código comunica . Cuando los métodos de un objeto siempre devuelven el objeto, comunica un par de cosas:

1. Necesito una configuración avanzada que no sea necesariamente obvia en qué orden se deben configurar o configurar las cosas
2. Cada llamada de método posterior se basa en el último

Caso de uso válido: consultas de base de datos ad hoc

Las bibliotecas de clases existen en la mayoría de los idiomas que le permiten consultar una base de datos sin recurrir a SQL codificado. Tome el Entity Framework para .NET como ejemplo:

DBContext db = new DBContext();
List<Post> posts = db.Posts
    .Where(post => post.Title.Contains("Test"))
    .OrderBy(post => post.DateCreated)
    .ToList();

Esta es una interfaz fluida donde cada llamada de método posterior se basa en la anterior. Leer estas llamadas lógicamente tiene sentido en el contexto de consultar una base de datos.

Caso de uso no válido: azúcar sintáctico para establecer propiedades

Ahora usemos el mismo patrón con la Postclase:

public class Post
{
    public string Title { get; set; }
    public DateTime DateCreated { get; set; }
    public string Body { get; set; }

    public Post SetTitle(string title)
    {
        Title = title;

        return this;
    }

    public Post SetDateCreated(DateTime created)
    {
        DateCreated = created;

        return this;
    }

    public Post SetBody(string body)
    {
        Body = body;

        return this;
    }
}

Ahora veamos cómo usarías esta clase:

Post post = new Post()
    .SetTitle("Test")
    .SetDateCreated(DateTime.Now)
    .SetBody("Just a test");

Cuando veo este código, inmediatamente hago esta pregunta: "Después de llamar SetBody , ¿consulta la base de datos? ¿Necesito llamar a otro método para decir 'Ya terminé?'"

¿Qué comunican las llamadas al método encadenado al código usando la Postclase?

1. Tengo una configuración complicada
2. Cada llamada al método se basa en la anterior

¿Es esto realmente cierto? No. La Postclase no tiene una configuración complicada. Establecer el título, la fecha de creación y el cuerpo no complementan entre sí hacia un objetivo final más complicado. Has machacado una clavija cuadrada en un agujero redondo.

El inconveniente del encadenamiento de métodos autorreferencial es que usted comunica que se requieren múltiples llamadas a métodos para hacer algo, y que cada llamada se basa en la última. Si esto no es cierto, entonces el encadenamiento de métodos podría estar comunicando lo incorrecto a otros programadores.

Cuando tus compañeros de trabajo dijeron:

Las interfaces fluidas no deben implementarse solo por conveniencia, sino también por semántica

Eran absolutamente correctos. Una interfaz fluida, o encadenamiento de métodos, comunica algo en sí mismo que podría no ser cierto.

El principal inconveniente es la pérdida de claridad. Por ejemplo:

x.foo();
x.bar();
x.baz();

Como ninguna de esas declaraciones devuelve un valor (o si lo hacen, se ha ignorado), solo pueden ser útiles si producen efectos secundarios. Contraste eso a:

x.foo()
 .bar()
 .baz();

Primero, no está claro eso bary bazopera en objetos del mismo tipo que x, a menos que sepa de hecho que esa xclase es la única clase con esos métodos. Incluso si ese es el caso, no está claro si funcionan los métodos xo los objetos nuevos.

Resaltar las partes del código que tienen efectos secundarios es útil, ya que necesita rastrear esos efectos secundarios para razonar sobre el programa. Debe sopesar la posible pérdida de claridad frente a la ganancia potencial en la facilidad de escribir código, pero también considere que el código se lee más de lo que se escribe.

Considere todos los elementos estilísticos de los lenguajes de programación (a diferencia del lenguaje de máquina de codificación manual), y debilita el argumento de "semántica no conveniencia".

Mucho de lo que hacemos como ingenieros es proporcionar comodidad en torno a la semántica.