Метод получения, который не обязательно получает значение члена?

Скажем, у меня есть класс C++, который содержит массив.

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

Однако как бы вы классифицировали аналогичную функцию, которая вместо этого просто возвращает логическое значение в зависимости от того, существует ли значение в массиве?

Эта функция "получает" что-то, но не обязательно значение от члена класса. Будет ли это по-прежнему считаться методом получения?


person Rustang    schedule 09.08.2018    source источник
comment
Что такое геттер-метод в вашей книге? Действительно ли имеет значение, является ли эта вещь методом получения или нет?   -  person Vittorio Romeo    schedule 09.08.2018
comment
@VittorioRomeo - Точно!   -  person Rizwan    schedule 09.08.2018
comment
IMO: методы Getter возвращают (получают) значение подобъекта, хранящегося внутри объекта. Однако этот метод выполняет операцию над данными и возвращает результат такой операции, поэтому я бы не стал классифицировать его как метод получения. Основываясь на вашем описании, любой метод с типом возврата, отличным от void, будет считаться геттером, поскольку все они что-то получат.   -  person Algirdas Preidžius    schedule 09.08.2018
comment
Геттер имени обычно используется для функций, которые возвращают значение члена. Точно так же сеттер обычно относится к функции, которая изменяет член. Основное использование этих функций состоит в том, чтобы убедить себя в том, что ваш интерфейс не раскрывает никаких внутренних деталей реализации, хотя это и так.   -  person molbdnilo    schedule 09.08.2018
comment
Всем спасибо, доволен новой точкой зрения, мой лектор сделал акцент на именовании в данной ситуации. Кажется, все согласны с тем, что это тривиально. Ty за направляющие комментарии.   -  person Rustang    schedule 13.08.2018
comment
Возможно, еще одна вещь, на которую следует обратить внимание, заключается в том, что если есть ценность для функций-получателей, которые реализованы для простого возврата переменной-члена, одна из них, помимо того, что делает невозможным изменение переменной вне класса, заключается в том, чтобы превратить их в не-получатели в будущее. Если у вас есть геттер-функция, такая как sum(), вам может быть полезно в будущем вычислять ее на лету вместо того, чтобы просто возвращать переменную-член, чтобы, скажем, сделать так, чтобы классу требовалось меньше блокировок для многопоточности — что-то вроде этого (всего одна примерная причина).   -  person    schedule 03.12.2018
comment
... тогда как, если бы переменная была раскрыта, то внезапно такое изменение потребовало бы изменения всего внешнего кода, непосредственно обращающегося к этой переменной, вместо того, чтобы просто изменить локальную реализацию этой одной функции-получателя (которая впоследствии больше не будет получателем, а вместо этого стать похожей на вычислительную функцию). Геттеры - очень неинтересные функции, и я думаю, что наличие многих из них является признаком потенциально плохого дизайна интерфейса, но у них есть это достоинство, когда они используются сами по себе, когда вы можете заставить их что-то вычислять в будущем вместо того, чтобы просто возвращать значение члена.   -  person    schedule 03.12.2018


Ответы (1)


Это действительно имеет значение? Рассмотрим этот интерфейс:

struct Adder {
    Adder(int a,int b);
    int get_sum();
};

для пользователя этого класса вообще не должно иметь значения, такова ли реализация:

struct Adder {
    Adder(int a,int b) : a(a),b(b) {}
    int get_sum() { return a+b; }
private:
    int a,b;
};

или это:

struct Adder {
    Adder(int a,int b) : c(a+b) {}
    int get_sum() { return c; }
private: 
    int c;
};

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

person 463035818_is_not_a_number    schedule 09.08.2018
comment
Я согласен. Грамотное определение/описание интерфейсных функций не должно зависеть от реализации. - person Giulio Franco; 09.08.2018