Вопрос конечно не сюда, но куда не знаю

Допустим есть класс, от которого должны наследоваться другие классы, у него есть публичный метод init, который делает что-то, в том числе вызывает protected метод этого же класса, который должен быть переопределен в дочерних классах. Как назвать этот protected метод?

Здравствуйте, Рома Мик, Вы писали:

РМ>Вопрос конечно не сюда, но куда не знаю

РМ>Допустим есть класс, от которого должны наследоваться другие классы, у него есть публичный метод init, который делает что-то, в том числе вызывает protected метод этого же класса, который должен быть переопределен в дочерних классах. Как назвать этот protected метод?

userInit

Здравствуйте, Рома Мик, Вы писали:

РМ>Допустим есть класс, от которого должны наследоваться другие классы, у него есть публичный метод init, который делает что-то, в том числе вызывает protected метод этого же класса, который должен быть переопределен в дочерних классах. Как назвать этот protected метод?

В общем виде,

virtual void init_impl() = 0;

А если этот метод специфичен для каждого конкретного класса (например, рукодельная рефлексия), — то так и назвать

virtual void init_type_specific_info() = 0; // TODO override in EVERY subclass

Здравствуйте, Рома Мик, Вы писали:

РМ>Допустим есть класс, от которого должны наследоваться другие классы, у него есть публичный метод init, который делает что-то, в том числе вызывает protected метод этого же класса, который должен быть переопределен в дочерних классах. Как назвать этот protected метод?

кэп: InitOverride. Для поклонников Кэррола — InitOverrideMe, разумеется.

В дотнете одно время предлагался суффикс Core, но на практике он оказался удобнее для методов "не лезь, если не хочешь сломать".

Здравствуйте, Рома Мик, Вы писали:

РМ>Вопрос конечно не сюда, но куда не знаю

РМ>Допустим есть класс, от которого должны наследоваться другие классы, у него есть публичный метод init, который делает что-то, в том числе вызывает protected метод этого же класса, который должен быть переопределен в дочерних классах. Как назвать этот protected метод?

Если должен быть переопределен для всех наследников, то может стоит сделать этот метод абстрактным? Это приведет к тому, что класс, от которого должны наследоваться, сам станет абстрактным, и будет выступать в роли шаблона для своих наследников. Тогда мороки с названием и не будет.

Здравствуйте, Рома Мик, Вы писали:
РМ>Допустим есть класс, от которого должны наследоваться другие классы, у него есть публичный метод init, который делает что-то, в том числе вызывает protected метод этого же класса, который должен быть переопределен в дочерних классах. Как назвать этот protected метод?
че-то я старею. так и хочется вскочить и крикнуть, показывая пальцем — наркоман!

такая вещь называется конструктор

Здравствуйте, __kot2, Вы писали:

__>че-то я старею. так и хочется вскочить и крикнуть, показывая пальцем — наркоман!
__>такая вещь называется конструктор

Конструктор вызывается при создании объекта (экземпляра класса), деструктор соответственно при уничтожении. Если эти действия нежелательны, то можно наклепать дополнительные методы.

Здравствуйте, velkin, Вы писали:
V>Здравствуйте, __kot2, Вы писали:
__>>че-то я старею. так и хочется вскочить и крикнуть, показывая пальцем — наркоман!
__>>такая вещь называется конструктор
V>Конструктор вызывается при создании объекта (экземпляра класса), деструктор соответственно при уничтожении. Если эти действия нежелательны, то можно наклепать дополнительные методы.
ну так конструктор он, соб-но для инициализации обьекта и создан. если вы снова его инициализируете — вы создаете новый обьект.
вы хотите переиспользовать какие-то буферы от другого сконструированного обьекта? ну так передайте их конструктору

Здравствуйте, __kot2, Вы писали:

__>ну так конструктор он, соб-но для инициализации обьекта и создан. если вы снова его инициализируете — вы создаете новый обьект.

Конструктор не всегда удобен. Первый пришедший в голову сценарий: дерево компонентов, надо вызывать Init() только после добавления дерева на форму.

Здравствуйте, Sinix, Вы писали:
S>Конструктор не всегда удобен. Первый пришедший в голову сценарий: дерево компонентов, надо вызывать Init() только после добавления дерева на форму.
это очень плохо, когда у вас допускается обьект в состоянии "не до конца создан", "не совсем убит" или вообще в каком-то невалидном состоянии. ни разу не видел, чтобы это работало надежно. помните, недавний разговор про глюк в скайпе с дублированием контактов? https://community.skype.com/t5/Mac-archive/double-contacts/td-p/629507 это вот как раз оно — сайд-эффекты раздельного вызова init при добавлении компонента в дерево на форму

Наверное это плохой вариант, но для полноты информации — в Java почему-то часто в таких случаях используют префикс do, например doInit.

В Objective C часто используются имена вроде viewWillLoad/viewDidLoad. Это уже лучше. Т.е. в вашем случае будет что-то вроде objectWillInitialize/objectDidInitialize. Мне этот вариант нравится больше остальных.

Здравствуйте, __kot2, Вы писали:

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

Здравствуйте, Рома Мик, Вы писали:
__>>такая вещь называется конструктор
РМ>Иногда бывает так, что конструктор не годится. Или его использование требует каких-то сильно больших телодвижений. В данном случае, объекты создаются, в конструкторе делают некую начальную инициализацию, в том, числе рассказывают какие другие объекты им нужны для продолжения инициализации, и потом в нужном порядке они все инициализируются.
это ужасно, просто ужасно

Здравствуйте, __kot2, Вы писали:

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

Простейшие примеры — данные, подтягиваемые через ORM, лениво заполняемые свойства у AST, настраиваемый логгер, объекты, создаваемые через builder pattern и т.д. и т.п.

Но можно начать с стартового примера. Ок, как по-вашему должно инициализироваться дерево UI-компонентов?
С учётом того, что его _сначала_ надо построить, и только затем добавить на форму.


__>ни разу не видел, чтобы это работало надежно.
Ну, если меры по предотвращению заканчиваются на "это ужасно, просто ужасно" — то очевидно да
Если не лениться и приправить код тестами / ассертами + отладочными инвариантами, то ошибки не пройдут

Здравствуйте, Sinix, Вы писали:
S>Но можно начать с стартового примера. Ок, как по-вашему должно инициализироваться дерево UI-компонентов?
S>С учётом того, что его _сначала_ надо построить, и только затем добавить на форму.
я просто работал на нескольких подобных проектах еще после универа. UI вообще провоцирует на подобный говнокод. это не значит, что нельзя сделать по-другому. просто вроде как "удобнее" иметь сложную запутанную логику заполнений обьектов и изменений их состояний.
вы никогда не сможете протестировать это автоматически
и вы убьете кучу своего времени, там, месяцы, на то, чтобы заставить это хоть как-то работать
и оно все равно толком работать не будет

поэтому это ужасно, просто ужасно

обьект конструируется в конструкторе. вы можете это сделать по-другому, но на это должна быть веская причина. "мне так удобнее" и "я так привык" это не причина. должна быть причина по котрой вы именно не можете конструировать его в конструкторе и никак не можете обойти это ограничение

Здравствуйте, __kot2, Вы писали:

__>обьект конструируется в конструкторе. вы можете это сделать по-другому, но на это должна быть веская причина. "мне так удобнее" и "я так привык" это не причина. должна быть причина по котрой вы именно не можете конструировать его в конструкторе и никак не можете обойти это ограничение

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

Здравствуйте, baily, Вы писали:
B>Вам и привели пример с веской причиной чуть выше. Даже сделали это два раза. Если вы не считаете данную причину веской а относите ее к категории отмазок, то приведите пример, как можно сделать просто и надежно только на конструкторах.
и где этот пример интересно? где код?
у меня не такая буйная фантазия, чтобы представить его. я даже не понимаю, разгоор идет о вебе, где нужно транслировать в html, об игре, где каждый кадр все перерисовывается или о простигоссподи windows-MFC со всякими его refresh и update.
в каждом случае будут наркоманские причины использовать частичносозданные обьекты и, если это правда интересно, я могу показать, как это сделал бы здоровый человек

Здравствуйте, __kot2, Вы писали:

S>>Но можно начать с стартового примера. Ок, как по-вашему должно инициализироваться дерево UI-компонентов?
S>>С учётом того, что его _сначала_ надо построить, и только затем добавить на форму.

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

Конкретику плиз, пример выше Раздел профильный, это не философия для потрындеть и "вот это — отстой" без аргументов не катит

Если конкретики не будет — топик надо в философию снести.

Здравствуйте, __kot2, Вы писали:

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

Здравствуйте, Рома Мик, Вы писали:
РМ>На самом деле да. Мне тоже не очень нравится в итоге. Но вариант введения дополнительного класса, который будет хранить параметры инициализации пока они не понадобятся, мне тоже кажется очень плохим, т.к. при создании нового типа объекта придется делать два класса вместо одного, а это морока.
РМ>Ну а чтобы избежать проблем недоинициализированные объекты хранятся внутри системы инициализации, которая их не отдает наружу пока они не проинициализируются.
я лично вообще не понимаю зачем обязат иметь недоиниц обьекты
вот мы пишем скайп. у нас есть контакты. есть класс их представления ContactView и контроллер — ContactController

Contact содержит в себе просто инфу о контакте — там, id, имя

struct Contact
{
  id_t id, string nickname;
};

ContactView использует станд компонент нашего гуя - TreeView и слушает инфу об изменении контактов

struct ContactView : public ContactListener
{
  TreeView tree_view;

// ContactListener intervace
  virtual void onload(const Contacts &contacts)
  {
    for (auto &c : contacts)
      tree_view.add_node(ContactItemView(c)); // или просто как вызов on_add()
  }

  virtual void onremove(const Contact &c)
  {
     tree_view.remove(find_tree_node(c));
  }
  .. + on_add + on_change - который может быть реализован для начала просто как on_remove(), on_add()
};

есть ContactController
{
  ContactListener &listener;
  Contacts contacts;
  ContactController(SerializationStuff &s, ContactListener &listener)
  {
    s >> contacts;
    listener.onload(contacts);
  }

  void add(id)
  {
    contacts.push_back(Contact(id));
    listener.onadd(*contacts.rbegin());  
  }
}

где ContactItemView : public TreeItemView
{
  ContactItemView(const Contact &c) : TreeItemView(c.nickname)
  {
     if (birthday(c))
       add_cake();
  }

  add_cake()
  {
    set_image(Image::CAKE)
  }
}

ну и в чем проблема-то? это самый стандартный тупой лобовой способ это сделать.