Действительно ли хорошо иметь весь возврат функций метода set ссылка на объект в C++?

You can return a reference to this if you want to chain setter function calls together like this:

obj.SetCount(10).SetName("Bob").SetColor(0x223344).SetWidth(35);

Personally I think that code is harder to read than the alternative:

obj.SetCount(10);
obj.SetName("Bob");
obj.SetColor(0x223344);
obj.SetWidth(35);

Если ваша мотивация связана с цепочкой (например, предложение Брайана Энсинка), я бы предложил два комментария:

1 , Если вы обнаружите, что часто настраиваете много вещей одновременно, это может означать, что вы должны создать класс struct или , который содержит все эти настройки, так что все они могут быть переданы одновременно. Следующим шагом может быть использование этого класса struct или в самом объекте ... но поскольку вы используете методы получения и установки, решение о том, как его представить внутренне, будет прозрачным. в любом случае, для пользователей класса, так что это решение будет больше касаться того, насколько сложен класс, чем что-либо еще.

2. Одной из альтернатив сеттеру является создание нового объекта, его изменение и возврат. Это неэффективно и неуместно в большинстве типов, особенно в изменчивых. Однако этот вариант иногда забывают, несмотря на то, что он используется в строковом классе многих языков.

Типичное назначение этого стиля - используется для построения объекта.

Person* pPerson = &(new Person())->setAge(34).setId(55).setName("Jack");

вместо

Person* pPerson = new Person( 34, 55, "Jack" );

. Используя второй более традиционный стиль, можно забыть, было ли первое значение, переданное конструктору, возрастом или идентификатором? Это также может привести к появлению нескольких конструкторов, основанных на достоверности некоторых свойств.

Используя первый стиль, можно забыть установить некоторые свойства объекта и привести к ошибкам, когда объекты не «полностью» построены. (Свойство класса добавляется позже, но не все места строительства были обновлены для вызова требуемого установщика. )

По мере развития кода мне очень нравится тот факт, что я могу использовать компилятор, чтобы помочь мне найти все места, где создается объект, при изменении сигнатуры конструктора. Поэтому по этой причине я предпочитаю использовать обычные конструкторы C ++ вместо этого стиля.

Этот шаблон может хорошо работать в приложениях, которые со временем поддерживают свою модель данных в соответствии с правилами, аналогичными тем, которые используются во многих приложениях баз данных:

• Вы можете добавить поле / атрибут таблицы / класса, который по умолчанию равен NULL. (Таким образом, для обновления существующих данных требуется просто новый столбец NULL в базе данных.)
• Код, который не является изменениями, должен работать так же, как и при добавлении этого поля NULL.

Сеттеры IMO - это запах кода, который обычно указывает на одну из двух вещей:

Создание Mountian из Molehill

Если у вас есть такой класс:

class Gizmo
{
public:
  void setA(int a) { a_ = a; }
  int getA() const { return a_; }

  void setB(const std::string & b) { v_ = b; }
  std::string getB() const { return b_; }
private:
  std::string b_;
  int a_;
};

... и значения действительно такие простые, то почему бы просто не сделать общедоступными элементы данных?:

class Gizmo
{
public:
  std::string b_;
  int a_;
};

... Намного проще и, если данные настолько просты , то вы ничего не теряете.

Другая возможность состоит в том, что вы могли бы

делать мол из холма

Во многих случаях данные не так просты: возможно, вам придется изменить несколько значений, выполнить некоторые вычисления, уведомить другой объект; кто что знает Но если данные достаточно нетривиальны, так что вам действительно нужны сеттеры и геттеры, то нетривиально достаточно и обработки ошибок. Так что в этих случаях ваши добытчики и сеттеры должны возвращать какой-то код ошибки или делать что-то еще, чтобы указать, что произошло что-то плохое.

Если вы объединяете в цепочку вызовы, как это:

A.doA().doB().doC();

... и doA () терпит неудачу, вы действительно хотите быть в любом случае вызывать doB () и doC ()? Я сомневаюсь в этом.

Я бы так не думал. Как правило, вы думаете, что объект «сеттер» делает именно это.

Кроме того, если вы просто устанавливаете объект, у вас нет указателя на него?

Не все установщики, но некоторые из них могут возвращать ссылку на объект, чтобы быть полезными.

вид

a.SetValues(object)(2)(3)(5)("Hello")(1.4);

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

SqlBuilder builder;

builder.select( column1 )( column2 )( column3 ).
    where( "=" )( column1, value1 )
                ( column2, value2 ).
    where( ">" )( column3, 100 ).
    from( table1 )( "table2" )( "table3" );

Я не смог воспроизвести источники за 10 минут. Так что реализация за кулисами.

Эта техника используется в Идиоме именованного параметра