Когда возвращать this вместо void в методе и почему?

Каковы преимущества (или недостатки) возврата ссылки на объект this в методе, который изменяет себя? Когда следует использовать возвращение this вместо void?

Глядя на ответ об обмене стеком проверки кода, я заметил, что в ответе используется Самостоятельный метод работы.

Упрощенный класс из оригинала:

class Item
{
    public Item(string name)
    {
        Name = name;
    }

    public string Name { get; private set; }

    public Item AddComponent(ItemComponent component)
    {
        _components.Add(component);
        return this;
    }

    private List<ItemComponent> _components = new List<ItemComponent>();
}

Упрощенный код использования:

var fireSword = new Item("Lightbringer")
                   .AddComponent(new Valuable { Cost = 1000 })
                   .AddComponent(new PhysicalDamage { Slashing = 10 });

Связанный вопрос, похоже, имеет противоречивые ответы разные пользователи.

Этот вопрос также аналогичен ответу ссылки на свободные интерфейсы для использования при создании объектов.


oop c# method-chaining fluent-interface
person Lazy Turtle    schedule 06.12.2020    source источник
comment
Потому что тогда вы можете связать вызовы методов. Только для удобства ... в примере было бы другое решение, например AddMany метод, который принимает контейнер или около того.   -  person JHBonarius    schedule 07.12.2020
comment
Этот шаблон часто называют fluent api.   -  person David Waterworth    schedule 07.12.2020

Ответы (1)


arrow_upward
4
arrow_downward

При возврате this используется дизайн свободный интерфейс, особый случай цепочки методов, когда тип возвращаемого значения - текущий объект на котором мы применяем метод.

Цепочка методов также является основой функционального программирования.

Он широко используется методами расширения Linq с IEnumerable<> и IQueryable<>.

Это позволяет вызывать методы одного и того же объекта в цепочке, не повторяя имя переменной для каждого вызова метода.

Следовательно, это дает более короткий, чистый и удобный в обслуживании код с меньшим количеством источников ошибок.

Поэтому мы используем это, когда хотим или в этом нуждаемся.

person Olivier Rogier    schedule 06.12.2020