Параметры в конструкторе

[Scorp__)]

Давно меня мучает такой вопрос и внятного ответа в книжках я на него не нашел.

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

Но что делать, когда у объекта десяток полей или больше и все они имеют значение для его работоспособности? Длинный список аргументов - некузяво. Заполнение полей по умолчанию также не выход, потому что сложно выделить наиболее популярные значения.

Пока мне приходит в голову только одно: упаковать все параметры в структуру, предоставить ее интерфейс пользователю и передавать конструктору указатель на эту структуру. Но вроде как выходит введение новой сущности; кроме объекта есть еще "поля объекта".

Может быть кто-то знает общепринятое решение? Или хоть какое-нибудь другое решение, которое выглядит лучше?

[Алексей++]

Scorp__), да, именно структура - самое подходячее решение в этом случае. Я бы даже сказал - самое удобное , потому автоматически так получится, что она (структура) пригодится вовсе не только в конструкторе.

для "целостности" (если мучает вопрос о "введении новой сущности" ) можно описать данную структуру внутри класса твоего объекта. Но, как показывает практика, иногда просто необходимо, чтоб структура было описана вне объекта

[Джон]

Лучше чем структура тоже не знаю.

[Scorp__)]

Да, вот так думаешь, что есть какое-то еще сакральное знание, а оказывается, что лучше чем уже делал и сделать нельзя...

А мне до сих пор в это не верится

[Джон]

ИМХО лучше думать, что существует лучшее решение, чем думать, что найденное решение самое лучшее и окончательное.
Здоровые сомнения ещё ничему никогда не вредили. В противном случае - признаки застоя.

Да и кстати, ставить окончательный крест на доп. ф-ях тоже не следует.

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

Тут всё зависит от определения "вменяемое состояние" и "готов к исполнению". Кто, к примеру, кроме объекта сможет лучше всего определить валидность параметров? Только он сам. А как это сделать в конструкторе?

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

Короче говоря в зависимости от ... оба способа имеют равное право на существование и применение.

[Антон (LogRus)]

Я за структурку в качестве параметра.

Джон, Инициализация объекта вне конструктора, через всякие init ИМХО это C, а не C++, если есть ошибки при создании, должно быть исключение.(точка), если конечно НУ ОЧЕНЬ нужно оставить объект в живых после неудачно переданных параметров, то можно и переинициализировать помните iostream

пересоздание объекта операция часто очень дешевая это не то место на котором надо экономить, для объектов на стеке еще дешевле.

ИМХО реализуя init люди не явно создают некое подобие синглетона
а синглетон чаше несёт вред чем пользу.
кроме это создание init/reset провоцирует пользователя класса/объекта использовать его там где не надо.
например, есть структура у неё есть конструктор по умолчанию и метод reset делают одно и тоже(конструктор зовёт reset), зачищают какие-то данные
я заполняю эту структруру какимито данными потом отдаю её функции пускай SetSomeFlags, она там что-то делаем с частью данных, что-то меняет, НО какой-то умник решил что он просто обязан внутри функции вызвать reset перед заполнением флагов. Какого спрашивается святого сбросил все данные, кто ему разрешал, где в названии функции указано, что она сбросит все данные, надо было назвать её ResetAndSetSomeFlags.

Я не разу не встречал ситуации, когда ДЕЙСТВИТЕЛЬНО нужно использовать init/reset
это же касается синглетонов.

[Джон]

LogRus, мы снова возвращаемся к проблеме широко освещаемой в темах a la "define=зло".

Так и хочется сказать: "Топор".

ДА! Есть такие ситуации, когда конструктор лучше, а init просто недопустима. А есть и наоборот. Причём здесь C или С++?

Примеров - куча. Взять хотябы чтение данных из файла (допустим некой конфигурации). Объект представляет собой элемент списка и должен быть проинициаллизирован данными из файла. Причём файл выбирает пользователь, "errare юзер est" как любили говаривать программеры в древнем Риме.
Он 10 раз подряд выбирает НЕ ТОТ файл (причин приводить не буду их тоже может быть куча). И что? Каждый раз вызывать исключение? Создавать целый механизм исключений (объекты, алгоритм обработки), загромождать код в месте создания объекта именно для данного случая? Хотя, конечно на вкус да на цвет товарищей нет.

Кстати другой пример. Объекты типа "окно". Работают в связке конструктор+Create. Аналог приведённого тобой reset - ф-я Destroy. И что? ЭТо тоже надо реализовать через исключения?

[Антон (LogRus)]

Джон, да я так считаю

а C ту при том, что это моё мнение что так пишут на C? а не на C++ в C++? есть исключения не дающие оверхеда в случае отсутсвия ошибок ну оверхед при ошибках ну так фиг с ним у нас нет цели работать быстро в моменты когда хрупкая реальность летит в тартар. в общем твои примеры не убедительны не вижу, где можно загромоздить код.

while (!flag)
{
   try{
     SomeClass someClass(SelectFile());
     flag = true;
   }
   catch(ErrorFile &e)
   {
     ShowMessage(e.what());
   }
}

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

[RXL]

LogRus, а разве это длинее?

Код:

while (!flag)
{
    SomeClass someClass;

    if (someClass.init(SelectFile()))
        flag = true;
    else
        ShowMessage("error");
}

или более логично

Код:

SomeClass someClass;

while (!someClass.init(SelectFile()))
{
        ShowMessage("error");
}

Главное достоинство try-catch в передаче аргумента. В остальном это громоздко, особенно, если нужно обработать в одном блоке много разных типов ошибок (их еще и описать надо отдельным классом).

[nikedeforest]

Это хорошо, ты завел статусную переменную, которая может принимать только два значения. А если у тебя будет не два состояния, а больше?  Преимущество try-catch в том, что эта конструкция позволяет избежать кода большой вложенности (большие совокупности if-else) и не использовать статусных переменных. Т.е. получается, ты при помощи try-catch можешь выделить номинальный код и код обработки ошибки, что более логично и более удобно. Думаю, последний довод не в счет .
Хоть как бы сейчас уже принято отходить от программирования в стиле СОМ, но все же местами встречаются предостережения о том, чтобы не использовать повсеместно try-catch, а рассматривать в том числе возможность обработки ошибок с помощью условного оператора. Вот только грань эта размыта, как мне кажется.
Чем-то спор похож на спор по поводу goto

[RXL]

nikedeforest, точно также:

Код:

MyClass var;
int error;

while((error = var.method()))
{
  switch(error)
  {
    case 1: ....; break;
    case 2: ....; break;
    case 3: ....; break;
    default: ...; break;
   }
}

Дело привычки и стиля. Оба метода имеют право на существование, имеют свои достоинства и недостатки.

[nikedeforest]

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

[Алексей++]

о, кстати. Насчёт try-catch . Тоже часто применяю везде подряд, а тут в соседней теме реализовывал код Хаффмана, там в одном месте идет работа с каждым байтом файла (то есть переходов - хренова туча). Сначала сделал for и вложенный switch, но обломался с выходом из свича и одновременно из for (на самом деле там всё проще оказалось, но речь вот о чём - )
заменил было на try, и выход при помощи throw 0, оказалось - ТОРМОЗА. для любопытства временно заменил на goto (первый раз за всю практику ))) ) - тормоза ушли. Переделал с for снова (как нужно) - тормозов нету.
Вот так то, злоупотреблять try )

[Finch]

Алексей1153++, try-catch сам по себе очень тяжеловесный оператор. Так как, там срабатывают механизмы еше и операционной системы при появлении ошибки. Так что не удивительны и тормоза.  Из цикла можно выскочить с помошью оператора break. Хотя сам по себе оператор, как и goto,  также не приветствуется в коде в больших разбавлениях.

[Алексей++]

Finch,

это всё понятно, у меня было

Код:

for(..;..;..)
{
 ...
 switch(...)
 {
   case ...:
   {
      //отсюда выйти из for
   }
   break;
 }
 ...
}

[Finch]

Я в такой ситуации использую

Код:

bool flag=true;
int i=0;
while ((i<.....) && flag)
{
.......
switch(...)
 {
   case ...:
   {
      flag=false;
   }
   break;
 }
.......
i++;
}

[RXL]

Или еще вариант: условие выхода проверить после switch. Ведь switch может быть не единсвенным оператором в блоке...

[Алексей++]

я присваивал переменной N , которая в условии for(;N;) значение, которое приведёт к выходу из цикла, а в свиче вызывал continue. Но со вложенными циклами такая вещь уже не прокатит )

[RXL]

В Perl есть возможность указывать, к какому из вложенных циклов применяется оператор через метку цикла. Жаль, что в C/C++ такого не предусмотрели...

[Finch]

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

[Scorp__)]

Оп, спор опять перешел не туда

Джон, я как раз не отказываюсь от дополнительных функций инициализации. После того как пару раз мне пришлось столкнуться с тем, что мой объект оказался нереентерабелен, я стараюсь везде предоставить функции реинициализации, но желательно разделенные по группам параметров, ну и может быть одну общую, с тем же набором параметров, что у конструктора. Но еще не было случая, чтобы подход конструктор + init был жизненно необходим.

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

А вот скажите мне еще, раз уж тема пошла дальше. В процессе работы программы возникает ситуация, когда объект должен быть полностью реинициализирован, то есть возможно даже будет освобождена память из-под каких-то данных (может быть и для всех конструкций объекта) и выделена для нового размера этих данных. Имеет ли право на жизнь такая реинициализация, или лучше тихо-мирно убить объект и сделать новый? Удерживает от такого действия обычно одно: объект асинхронный и что-то там себе выполняет, у приложения есть указатель на него, у объекта есть указатель на событие в приложении, чтобы оповещать его о результатах, все друг друга знают короче и привыкли. А тут вдруг убить и заново знакомиться.

Вот и еще вопрос созрел А чем вы обычно пользуетесь для синхронизации разрозненных объектов? Когда один дает другому задание и занимается своими делами, а потом "подрядчик" должен сказать, что он все сделал, ну и разные вариации на эту тему: сообщить что пришла информация, сообщить что закончен обсчет, сообщить что в процессе анализа обнаружено что-то необычное. В общем как на С++ организуется этот самый обмен сообщениями между объектами, который является одной из основ ООП?

[Finch]

Scorp__), А у тебя что ли объекты работают в разных потоках?

[Scorp__)]

Finch, ага. Например захват видео и его обработку на лету в один поток не запихнуть.

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

[Finch]

Вот и еще вопрос созрел Улыбаюсь А чем вы обычно пользуетесь для синхронизации разрозненных объектов? Когда один дает другому задание и занимается своими делами, а потом "подрядчик" должен сказать, что он все сделал, ну и разные вариации на эту тему: сообщить что пришла информация, сообщить что закончен обсчет, сообщить что в процессе анализа обнаружено что-то необычное. В общем как на С++ организуется этот самый обмен сообщениями между объектами, который является одной из основ ООП? Улыбаюсь

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

[Антон (LogRus)]

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

можно callback или набор callback(список подписчиков на сообщение)

смотря, что лучше вписывается в архитектуру приложения

кстати offtop