Как запретить повторное использование конструктора?

[Сионист]

У Вас CObjectStorage - класс, декларированный глобально и IObject - класс, декларированный глобально. Получается, что можно создать экземпляр класса IObjectя который знать не будет ни о каких стореджах, а по условию это не имеет смысла. Чёрный ящик в ТАУ - объект, о котором вообще ничего не известно, кантовская вещь в себе, но в управленческий профиль, то есть со входами и выходами. По условию IObject - полуящик того же цвета. Так что без себе подобного он не имеет даже входов/выходов, с которыми хоть как то можно было бы работать. Есть ещё один класс A, почти обычный. Пользователь с гуя набирает значения поля IObject, обработчик события спрашивает класс, а какой же объект имеет такое значение поля, указатель именно на этот объект присваивается полю экземпляра A. Тоже самое делается для другого экземпляра A. А потом пользователь куда то жмёт мышкой и машина должна сказать, во сколько раз один экземпляр A больше другого. Ни в какой другой задаче IObject вообще не имеет смысла. Но у Вас он самостоятелен. Нафига эта сущность вообще нужна на этом уровне? Что, в коммерческом коде делают, как на лабе учили, забыв про требования конкретного проекта, чтоб потом упиваться академичностью? Уровень ваще то не тот, чтоб так делать. Я на это уже указал, а Вы продолжаете упираться, как школьный учитель, ни когда в жизни в глаза не видевший ни каких ТЗ и ни каких требований к софту.

[Romeo]

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

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

Вообще-то я расположил все классы для удобства в одном листинге. На самом деле объявления классов IObject и CObjectStorage должны быть вынесены в хедер, который будет включаться вызывающим кодом. А вот классы CObject, CRootObect и CAnyObject должны быть спрятаны в cpp файле, где расположенo определение класса CObjectStorage. Это позволит сокрыть имплементации объектов от вызывающего кода, благодаря чему вызывающей стороне будет доступен только GetObject и создать объекты напрямую не получится. Надеюсь, я достаточно доходчиво описал принцип работы фабричного метода. Если не понятно, то почитай о нём в интернете. Это такой же обобщённый паттерн проектирования, как и любимый тобой синглтон.

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

Неправильная трактовка. IObject - это интерфейс. Реальные классы для элементов множества - это CRootObject и CAnyObject. У CAnyObject как раз есть связь. Дочитать нужно было код просто...

Пользователь с гуя набирает значения поля IObject, обработчик события спрашивает класс, а какой же объект имеет такое значение поля, указатель именно на этот объект присваивается полю экземпляра A. Тоже самое делается для другого экземпляра A. А потом пользователь куда то жмёт мышкой и машина должна сказать, во сколько раз один экземпляр A больше другого.

Ага, то есть новый объект создаётся не на основании связи. Связь позже устанавливается? Это может потребовать пересмотра концепции. Хотя с другой стороны в предыдущих постах ты писал, что один элемент не имеет смысла без второго. Вот тут я запутался.

Ни в какой другой задаче IObject вообще не имеет смысла. Но у Вас он самостоятелен. Нафига эта сущность вообще нужна на этом уровне?

Ещё раз говорю, что IObject - это не класс, описывающий самостоятельный объект. Это всего лишь интерфейс. Объект этого класса создать невозможно. Тебе что-то говорит ключевое слово virtual и =0 в конце методов класса? Нафига нужен интерфейс, говоришь? А зачем вообще полиморфизм нужен? Зачем его объявили одной из составляющий частей ООП, не знаешь?

ни когда в жизни в глаза не видевший ни каких ТЗ и ни каких требований к софту.

Не путай DS (design specification) и FS (functional specification). В советской номенлатуре DS'у соответствует ТЗ (тех. задание), которое описывает постановку задачи и результат, который нужно достигнуть. Но DS никогда не содержит деталей того, как цель должна быть достигнута, так как DS часто пишется людьми, далёкими от программирования. Программист сам имеет право выбрать, как достичь желаемого результата, потому он пишет для себя FS и утверждает его у человека, который разбирается в этом (например у лидера команды или архитектора). Я к чему это веду. Если у тебя есть ТЗ, то никто не заставляет тебя строить архитектуру именно так, как ты её сейчас строишь. ТЗ содержит информацию о том, кто куда кликнул и что в результате вышло, а не внутреннюю структуру классов.

Так свой код не хочешь показать? Я хоть пойму тогда, как доработать свою модель.

[Сионист]

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

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

[Сионист]

Не путай DS (design specification) и FS (functional specification). В советской номенлатуре DS'у соответствует ТЗ (тех. задание), которое описывает постановку задачи и результат, который нужно достигнуть. Но DS никогда не содержит деталей того, как цель должна быть достигнута, так как DS часто пишется людьми, далёкими от программирования. Программист сам имеет право выбрать, как достичь желаемого результата, потому он пишет для себя FS и утверждает его у человека, который разбирается в этом (например у лидера команды или архитектора). Я к чему это веду. Если у тебя есть ТЗ, то никто не заставляет тебя строить архитектуру именно так, как ты её сейчас строишь. ТЗ содержит информацию о том, кто куда кликнул и что в результате вышло, а не внутреннюю структуру классов.

Профессор Верёвкин, например, имеет достаточно отдалённое представление о программировании. Но не о моделировании. Если человек не в состоянии обсуждать проект, то он такого в ТЗ напишет, что или самому придётся проектировать заново и находу, или ничего вообще не получится. А задачу, поставленную профессором Верёвкиным, можно решать, не правя задание после теста каждой строчки, и корректируя во-первых в диалоге с ним же, а во-вторых только то, что потом окажется нюансами, которых он не знал не в программировании, а в самой предметной области, только если приходится одновременно писать софт и исследовать то, для чего он пишется.

[Оксалайя]

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

Бред.

Так у кого здесь нет академических знаний?

Очевидно, что у Вас.

Скажите, Сионист, а зачем Вы спрашиваете совета, если считаете, что сам лучше знаете?
И что-то мне подсказывает, что показывать свой код Вам просто страшно...

[Romeo]

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

Ты написал, что можно создать экземпляр класса IObject, а не его потомка. Не нужно выкручиваться. После такого ответа я обычно заканчиваю собеседование и отказываю кандидату. У тебя сейчас уровень знаний языка не достаёт даже до планки Junior.

И если ответ на вопрос об академических знаниях всё ещё актуален, то я отвечу. У тебя их нет.

А про потомков. Я же чёрным по белому написал, что их определение должно быть сокрыто в cpp файле, в котором расположена имплементация CObjectStorage. Это не позволит из создать напрямую из вызывающего кода. Или ты не прочёл это? Специально для тебя копирую сюда ещё раз:

Вообще-то я расположил все классы для удобства в одном листинге. На самом деле объявления классов IObject и CObjectStorage должны быть вынесены в хедер, который будет включаться вызывающим кодом. А вот классы CObject, CRootObect и CAnyObject должны быть спрятаны в cpp файле, где расположенo определение класса CObjectStorage. Это позволит сокрыть имплементации объектов от вызывающего кода, благодаря чему вызывающей стороне будет доступен только GetObject и создать объекты напрямую не получится. Надеюсь, я достаточно доходчиво описал принцип работы фабричного метода. Если не понятно, то почитай о нём в интернете. Это такой же обобщённый паттерн проектирования, как и любимый тобой синглтон.

Знаешь, есть анекдот про чукчу, который писал книги и такая фигня получалась, что никто прочесть не мог. Его спросили, сумеет ли он сам прочесть, что написал. А он ответил "А зачем? Чукча - не читатель. Чукча - писатель". Вот такие же у меня сейчас ощущения, когда читаю твои посты.

[Romeo]

Профессор Верёвкин, например, имеет достаточно отдалённое представление о программировании. Но не о моделировании. Если человек не в состоянии обсуждать проект, то он такого в ТЗ напишет, что или самому придётся проектировать заново и находу, или ничего вообще не получится. А задачу, поставленную профессором Верёвкиным, можно решать, не правя задание после теста каждой строчки, и корректируя во-первых в диалоге с ним же, а во-вторых только то, что потом окажется нюансами, которых он не знал не в программировании, а в самой предметной области, только если приходится одновременно писать софт и исследовать то, для чего он пишется.

Погоди, ты сейчас споришь с общепринятыми нормами разработки? Ну красавец, что я могу сказать.

Я отлично помню, как год назад ты Страуструпа поливал грязью за то, что он динамическому массиву из STL дал имя vector. И с пеной у рта объяснял, что он недалёкий человек, раз путает такие понятия. А ещё выложил на страницы форума всё, что знал о геометрических векторах, хотя тебя никто не просил. Вот с каким выражением лица я тогда твои посты читал, с таким же читаю и сейчас. Сионист, ты просто плохо образованный человек, делающий вид, что на самом деле как минимум академик. И это без всяких оскорблений - это просто факт. Не выпячивай свою необразованность, это выглядит смешно для тех, кто действительно разбирается в сути вопроса. Лучше просто читай книжки, меньше говори и больше думай. Тогда будет толк какой-то.

[Сионист]

И, кстати, Оксалайя права. Было бы очень интересно посмотреть на твой код. Можешь выложить? Может тогда и никаких дополнительных объяснений по поводу "отношений" не понадобится.

Я рассказал достаточно.

[Romeo]

Я рассказал достаточно.

Ну значит и мы рассказали достаточно.

[Сионист]

Да. Но не о том. Решение уже есть.