Имеет ли смысл такой вид передачи аргументов в метод класса?

Question

[have_a_nice_day13]

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

class test_habr_t
{
public:
struct data_types_t
{
int number = 0;
} data_types;

void method_1(data_types_t& data_types) { data_types.number = 8; };
void method_2(data_types_t data_types) { printf("%i", data_types.number); };

];

И собственно у меня встаёт вопрос, а имеет ли смысл передавать структуру в виде параметра (с ссылкой)? если в виде аргумента будет допустимый идентификатор объявленный в классе.

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

Comments

[Евгений Шатунов]

have_a_nice_day13 , всё будет зависеть от смысла происходящего в коде.
Хорошо, у тебя есть тип данных с некоторым интерфейсом. Интерфейс этого типа построен так, что требует передачи каких-то данных параметром. Пока все абстрактно и непонятно.
Конкретика появится тогда, когда станет понятно, что это за тип данных и какой именно у него интерфейс. А так же - что за структура, экземпляр которой требуется для работы с интерфейсом обозначенного типа.

Есть т.н. шаблон "Toolbox", в рамках которого объект некоторого типа, используя свое состояние и свой интерфейс, позволяет менять состояние объектов некоторого другого типа.
Например, таким тулбоксом может быть краскопульт. Пример, в целом, некрасивый, но наглядный. В состояние краскопульта ты кладешь цвет краски, а потом через его метод распылить_на( кузов ) можешь покрасить кузов любой машины. При этом краскопульт поменяет состояние кузова машины.

Есть т.н. "Value Object" или еще его называют "Parameter Object", суть которого - это собрать какие-то данные для того чтобы дальше переместить их в функцию потому что функция для своей работы требует такой VO вместо каких-нибудь 16-ти или 23-х параметров.

Есть т.н. контекст, с которым может работать интерфейс большого объекта, реализуя, например, шаблон "Состояние".

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

Answer 1

[Wataru]

Не совсем понятен вопрос, но есть комментарии по стилю в method1. Лучше передавать указатель вместо неконстантной ссылки. Так из места вызова сразу видно, что передаваемое значение может меняться. На некоторых проектах это прописанно в правилах.

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

Comments

[have_a_nice_day13]

Wataru, Про стиль я тебя услышал, хорошо, буду действовать по такому методу. И нет, я не про имя параметра, я про то, что имеет ли смысл передавать в параметр структуру которая имеет объявление идентификатора доступа уже в самом классе, и собственно в метод будет передаваться именно через ранее объявленный идентификатор структуры в классе.

[Wataru]

have_a_nice_day13, приведи пример кода вызова.

Это нормально передавать или возвращать объявленный в классе тип. Но ты что ли хочешь передавать туда переменную член класса?

[have_a_nice_day13]

Wataru,

class test_t
{
public:
struct data_t
{
int number = 0;
} data;

void set(data_t& test_data) { test_data.number = 32; };
void print(data_t test_data) { printf("%i", test_data.number); };
};

int main()
{
test_t test;
test.set(test.data);
test.print(test.data);
}

[Wataru]

have_a_nice_day13, нет, так делать обычно не надо. Зачем вам параметр функции, если структура и так внутри доступна.

Вот если вы можете эту структуруот одного экземпляра test_t передовать другому, то может и есть смысл, но лучше тогда передать весь test_t. Или вынесите структуру из класса.

[have_a_nice_day13]

Wataru, поясните "Вот если вы можете эту структуруот одного экземпляра test_t передовать другому", не совсем понимаю

[Евгений Шатунов]

Wataru,

Лучше передавать указатель вместо неконстантной ссылки. Так из места вызова сразу видно, что передаваемое значение может меняться.

Указатель в параметре явно говорит о необязательности параметра и о том, что в качестве аргумента можно передать nullptr. Подобная семантическая нагрузка буквально неуместна в самом широком наборе вариантов, когда модификация аргумента оправдана.
Из места вызова модифицируемость параметра должна быть видна иначе. На выбор есть два 100% рабочих варианта: первый - через перемещение аргумента и возврат его в качестве результата функции; второй - через семантичное имя функции, которая однозначно говорит, что будет менять состояние параметра, например.

В качестве дополнения, в Core Guidelines есть F.16 и F.17.
Передача изменяемых параметров по указателю пропагандируется в Google C++ Style Guide, а этот стиль людьми сильно критикуется, например.

[Wataru]

have_a_nice_day13,

поясните "Вот если вы можете эту структуруот одного экземпляра test_t передовать другому", не совсем понимаю

test_t test1, test2;
test1.set(test2.data);

В данном тривиальном примере - это не имеет смысла, но может быть где-то и понадобится. Допустим у вас класс длинных чисел. И у него внутри хранится массив цифр. И вы хотите при сложении чисел передать одному числу этот массив цифр от другого. Но в этом случае правильнее передать целиком весь класс длинного числа.

Или надо сделать метод getData(), чтобы вызывать test1.set(test2.get()), если data_t - это что-то внешнее по отношению к test_t (например, у вас класс окна и у него есть обработчик события. Вам может захотеться передать обработчик события от одного класса другому.)