Недавно я предложил реализовать метод связывания для определенного класса в определенном проекте, чтобы можно было улучшить читабельность кода. Я получил ответ «беглые интерфейсы должны быть реализованы не просто для удобства, а для семантики», и мое предложение было отклонено. Я ответил, что я не предлагал свободный интерфейс, а сам метод цепочки ( их можно спутать друг с другом, читайте внизу), чтобы улучшить удобочитаемость и удобство кодирования, предложение было отклонено снова.

Во всяком случае, это заставило меня задуматься о том, что, возможно, я мог бы столкнуться с плохой практикой, всегда возвращая «this» в методах, которые не должны ничего возвращать (например, сеттеры).

Мой вопрос: может ли применение предыдущего соглашения считаться плохой практикой или злоупотреблением? Почему? Я не думаю, что есть какие-либо недостатки в производительности или есть?

нет

Как указывает Кент Бек , код читается гораздо чаще, чем пишется.

Если цепочка методов делает ваш код более читабельным, используйте цепочку методов.

Да, есть недостатки

Код, который легко читать, хорош, но также остерегайтесь того, что код также передает . Когда методы объекта всегда возвращают объект, он сообщает пару вещей:

1. Мне требуется расширенная конфигурация, которая не обязательно очевидна, в каком порядке все должно быть установлено или настроено
2. Каждый последующий вызов метода основывается на последнем

Допустимый вариант использования: специальные запросы к базе данных

Библиотеки классов существуют почти во всех языках, что позволяет запрашивать базу данных, не прибегая к жестко закодированному SQL. Возьмем Entity Framework для .NET в качестве примера:

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

Это свободный интерфейс, в котором каждый последующий вызов метода основывается на предыдущем. Логическое чтение этих вызовов имеет смысл в контексте запросов к базе данных.

Неверный вариант использования: синтаксический сахар для настройки свойств

Теперь давайте использовать тот же шаблон с Postклассом:

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;
    }
}

Теперь давайте посмотрим, как вы будете использовать этот класс:

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

Когда я вижу этот код, я сразу же задаю вопрос: «После вызова SetBodyзапрашивает ли он базу данных? Нужно ли вызывать другой метод, чтобы сказать« Я сделал? »»

Что связывают вызовы метода с кодом с помощью Postкласса?

1. У меня сложная настройка
2. Каждый вызов метода основан на предыдущем

Является ли это на самом деле так? Нет . PostКласс никак не имеет сложную настройку. Установка заголовка, даты создания и тела не основывается на более сложной конечной цели. Вы разбили квадратный колышек в круглое отверстие.

Недостаток связывания методов со ссылками на себя состоит в том, что вы сообщаете, что для выполнения чего-либо требуется несколько вызовов методов и что каждый вызов строится из последнего. Если это не так, то цепочка методов может сообщать неправильные вещи другим программистам.

Когда ваши коллеги сказали:

Свободные интерфейсы должны быть реализованы не только для удобства, но и для семантики

Они были абсолютно правы. Свободный интерфейс или цепочка методов сообщают о себе что-то, что может быть неверным.

Основным недостатком является потеря ясности. Например:

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

Поскольку ни один из этих операторов не возвращает значение (или, если они это делают, оно игнорируется), они могут быть полезны только в том случае, если они вызывают побочные эффекты. Сравните это с:

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

Во-первых, не ясно, что barи bazработают с объектами того же типа, что xи вы, если только вы точно не знаете, что xкласс является единственным классом с этими методами. Даже если это так, непонятно, как работают методы xили новые объекты.

Выделение частей кода, которые имеют побочные эффекты, полезно, так как вам нужно отслеживать эти побочные эффекты, чтобы рассуждать о программе. Вы должны взвесить потенциальную потерю ясности и потенциальную выгоду в простоте написания кода, но также учтите, что код читается больше, чем написано.

Рассмотрим все стилистические элементы языков программирования (в отличие от машинного языка ручного кодирования), и это ослабляет аргумент «семантика, а не удобство».

Многое из того, что мы делаем как инженеры, обеспечивает удобство в отношении семантики.