Developing.ru

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

Сионист писал(а):Получается, что можно создать экземпляр класса 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 и утверждает его у человека, который разбирается в этом (например у лидера команды или архитектора). Я к чему это веду. Если у тебя есть ТЗ, то никто не заставляет тебя строить архитектуру именно так, как ты её сейчас строишь. ТЗ содержит информацию о том, кто куда кликнул и что в результате вышло, а не внутреннюю структуру классов.

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

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

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

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

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

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

Бред.

Сионист писал(а):Так у кого здесь нет академических знаний?

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

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

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

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

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

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

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

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

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

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

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

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

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

Сионист писал(а):Я рассказал достаточно.

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

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