Изначально я из мира C # и изучаю C ++. Мне было интересно узнать о функциях get и set в C ++. В C # они довольно популярны, а такие инструменты, как Visual Studio, способствуют их использованию, делая их очень простыми и быстрыми в реализации. Однако в мире C ++ это не так.
Вот код C # 2.0:
public class Foo
{
private string bar;
public string Bar
{
get { return bar; }
set { bar = value; }
}
}
Или в C # 3.0:
public class Foo { get; set; }
Могут ли люди сказать, что в этом смысла? Почему бы просто не создать открытое поле, а затем сделать его свойством позже, если вам нужно; честно говоря, я на самом деле не уверен. Я просто делаю это из хорошей практики, потому что я видел это много раз.
Теперь, поскольку я так привык к этому, я чувствую, что должен перенести эту привычку на свой код C ++, но действительно ли это необходимо? Я не вижу, как это делается так часто, как с C #.
В любом случае, вот C ++ из того, что я собираю:
class Foo
{
public:
std::string GetBar() const; // Thanks for the tip Earwicker.
void SetBar(std::string bar);
private:
std::string bar;
}
const std::string Foo::GetBar()
{
return bar;
}
void Foo::SetBar(std::string bar)
{
// Also, I always wonder if using 'this->' is good practice.
this->bar = bar;
}
Теперь, для меня это похоже на большую работу ног; Учитывая использование инструментов Visual Studio, реализация C # заняла бы буквально секунды, а ввод C ++ занял у меня намного больше времени - я чувствую, что это не стоит усилий, особенно когда альтернатива имеет 5 строк:
class Foo
{
public:
std::string Bar;
}
Из того, что я понял, вот преимущества:
- Вы можете изменить детали реализации функций get и set, поэтому вместо возврата личного поля вы можете вернуть что-то более интересное.
- Вы можете позже удалить get / set и сделать его доступным только для чтения / записи (но для общедоступного интерфейса это не очень хорошо).
И недостатки:
- Печатает целую вечность, действительно ли это стоит усилий? Вообще говоря. В некоторых случаях преимущества оправдывают свои усилия, но я имею в виду, говоря словами «хорошая практика», правда?
Ответ:
Почему я выбрал ответ с меньшим количеством голосов ? На самом деле я был очень близок к выбору ответа veefu ; однако мое личное мнение (которое, по-видимому, является спорным) заключается в том, что ответ на вопрос о вареном пудинге.
Ответ, который я выбрал, с другой стороны, кажется, спорит обе стороны; Я думаю, что геттеры и сеттеры являются злом, если используются чрезмерно (я имею в виду, когда это не нужно и нарушит бизнес-модель), но почему бы нам не иметь функцию с именем GetBalance()?
Конечно, это будет гораздо более универсальным, чем PrintBalance(); Что, если я хотел показать это пользователю иначе, чем того хотел класс? Теперь, в некотором смысле, GetBalance() может быть недостаточно релевантным, чтобы утверждать, что «геттеры и сеттеры хороши», потому что у него нет (или, возможно, не должно ) иметь сопровождающий сеттер, и говорить о что, функция с именем SetBalance(float f) может быть плохой (на мой взгляд), потому что это подразумевает, что для реализации функции необходимо манипулировать учетной записью вне класса, что не очень хорошая вещь.