Stack со сменой представления

Здорова господа!!!

Есть задачка: "Напишите класс Stack, для которого можно сменить представление на стадии выполнения программы. Подсказка: "Любую проблему можно решить введя еще один уровень косвенности" "

Тут не понятно что нам нужно сделать. Рассмотрим просто теоретически, допустим есть у нас класс Stack и нам что нужно от него по создавать производные классы допустим А и допустим B. Создаем указатель на Stack *p И создаем указатель на A *pa и указателю p присваиваем указатель pa и у нас получится что мы изменили представление класса Stack, что бы еще поменять то мы создаем указатель B* pb со своим набором дополнительных функций снова присваиваем p = pb уже новое представление, это имелось введу. Хотя на стадии выполнения имелось в веду
dynamic_cast<>() понятно что перед выполнением мы приведем Stack к нужному типу.

Что понимается под сменой представления на стадии выполнения? Я понимаю полиморфизм имелся введу или что?

А эта строчка что означает: "Любую проблему можно решить введя еще один уровень косвенности" Что такое уровень косвенности, косвенности это как бы через промежуток обращение не на прямую, видимо нужно производные классы создавать.

Объясните новичку!!!!

0

Сообщение от vxg нам не нужно делать dynamic_cast. у нас будет абстрактный стек. и у него виртуальный метод, например, вставить. мы это метод расширим в классе, например, папка с файлами. расширим таким образом что бы вставка кроме стандартного поведения (обновления списка элементов стека) приводила к реальной вставке файла в папку. если мы создадим объект класса папка с файлами и передадим указатель на него в функцию которая принимает указатель на стек, то эта функция оперируя со стеком будет фактически обращаться к папке с файлами.

Ну да нам не нужно тут проверять dynamic_cast<> тут мы просто другой тип не передадим,

А от в варианте что я описал через указатель на Abstrakt_Stack нужно проверять обязательно, потому что мы можем определить класс C : public Abstrakt_Stack и не сделать еще : public Stack и если мы без dynamic_cast<>() обратимся к указателю Abstrakt_Stack а он будет указывать на объект C который не есть Stack и вызовем методы Stak() то будет ошибка, тут нужно обязательно проверять.

Добавлено через 5 минут

Сообщение от vxg очень все запутано, что то тут у вас не так)

Ну если Stack без виртуальных функций, то dynamic_cast<>() нельзя к такому классу применить. Мы можем от Stack унаследовать много классов, но проверять мы не сможем какой тип передается через указатель Stack*, от если Stack без виртуальных функций, мы делаем производные классы А, B и через указатель и есть fun(Stack* s) и мы передаем допустим в функцию указатель на А , f(new A()) то мы уже не сможем в самой функции видеть какой это класс А или B dynamic_cast<> не сможем применить. Нужно чтобы базовый класс обязательно был полиморфный.

Я возможно ошибаюсь, не сильно в этом шарю.

Нужно поэкспериментировать.

0

Сообщение от ninja2 А от в варианте что я описал через указатель на Abstrakt_Stack нужно проверять обязательно, потому что мы можем определить класс C : public Abstrakt_Stack и не сделать еще : public Stack и если мы без dynamic_cast<>() обратимся к указателю Abstrakt_Stack а он будет указывать на объект C который не есть Stack и вызовем методы Stak() то будет ошибка, тут нужно обязательно проверять.

не надо так. надо так /код для демонстрации - возможны неточности/

1

Сообщение от vxg зачем нам еще одно поле в классе? пусть даже абстрактного типа?

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

0

Сообщение от ninja2 проверять типы

зачем?

Сообщение от ninja2 Вообще я запутался фиг его знает.

наверно

0

Сообщение от vxg не надо так. надо так /код для демонстрации - возможны неточности/

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

0

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

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

0

Сообщение от vxg зачем?

Как зачем? А если у нас будет много наследников от Abstrakt_Stack и некоторые наследники будут не от Stack, а допустим от List и ты что в fun(Abstrakt_Stack*) определишь, что это не стек, а List ??? Без dynamic_cast<>() ты этого не сделаешь. Это я просто пример навел если будет такое.

Ну и еще пример без Abstrakt_Stack, просто с Stack ты поделал от него наследование и некоторым классам ты сделал двойное наследование расширил например A : public Stack, public List и тебе нужно в f(Stack*) знать что это именно класс A а не какой то там B, для того что бы вызвать специфические функции из класса List.

А от еще пример если ты просто сделал наследование от Stack производные классы А и производный класс B, в классе А есть метод print_A(), в классе B есть метод fff_B() специфические для производных классов, есть функция f(Stack* p) и ты должен в ней вызвать разные функции проверить если if(A*pp=dynamic_cast<A*>(p)) pp->print_A(); if(B* pp=dynamic_cast<B*>(p)) pp->fff_B(). Ну и как ты это все реализуешь без dynamic_cast ??? все в классе Stack определишь? А если производных классов у тебя будет не один, а 30 и для каждого нужно свои уникальные функции вызывать?

Это несколько вариантов их наверняка больше.

0

Сообщение от ninja2 и некоторые наследники будут не от Stack

а не надо так. точнее не так. можно наследовать хоть от 1001 класса, но программа должна строится таким образом что бы функции отдавали себе отчет в том с чем они работают и не использовали приведения. во всяком случае старались. если они используют приведение значит что то не так или задача очень специфичная (всем не угодишь)

0

Ну в принципе если их штук 30 будет то все можно в классе Stack определить сделать так это называется "Жирный интерфейс", но его я не помню точно вроде советуют избегать, хотя можно и так.

0

Сообщение от ninja2 если их штук 30 будет

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

0

Сообщение от vxg а не надо так. точнее не так. можно наследовать хоть от 1001 класса, но программа должна строится таким образом что бы функции отдавали себе отчет в том с чем они работают и не использовали приведения. во всяком случае старались. если они используют приведение значит что то не так или задача очень специфичная (всем не угодишь)

Ну ладно тут уже от проектирования зависит как спроектируешь

Но для реальных наследников А B у них же разные методы, мыж не можем сделать все в базовом классе и тупо вызывать из функции f(Stack*) виртуальные функции, нам же мб нужно для некоторых типов и свои вызвать, так что без приведения не обойтись.

0

Сообщение от ninja2 без приведения не обойтись

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

1

Сообщение от vxg но при правильном проектировании у вас никогда не возникнет желание использовать все эти представления в одной функции

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

0

Сообщение от ninja2 программистам сильно думать не нужно

выдвигайте фразу в номинации девиз форума)

1

Сообщение от vxg обойтись. функция принимающая стек не может нагло полагать что ей передано что то иное. она не должна приводить. иначе эта функция неправильная. ну, или, она Особенная) бывает что и приходится приводить, но это ммммм...

Да у стека не будет других свойств, но от щас попытаюсь привести пример "транспортное средство" абстрактный класс от него идет производный класс "машины", "самолеты", "корабли" и есть класс "ЭКСТРЕННЫЕ СЛУЖБЫ" и от у нас получается класс "МАШИНА СКОРОЙ ПОМОЩИ" производный от "машина" и от "экстренные службы", класс ПОЖАРНАЯ МАШИНА" производный от "машина" и "экстренные службы" и есть просто "ЛЕГКОВАЯ МАШИНА" от "машина" и "ГРУЗОВИК" от машина.

И есть функция fun(машина* p) и нам нужно в ней знать к какому классу машина относится если к службам то вызвать для них спецефические допустим виртуальные функции из "экстренных служб" и "машина", а если к машина, то просто функции "машина".

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

Добавлено через 1 минуту

Сообщение от vxg выдвигайте фразу в номинации девиз форума)

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

0

Сообщение от ninja2 Да у стека не будет других свойств, но от щас попытаюсь привести пример "транспортное средство" абстрактный класс от него идет производный класс "машины", "самолеты", "корабли" и есть класс "ЭКСТРЕННЫЕ СЛУЖБЫ" и от у нас получается класс "МАШИНА СКОРОЙ ПОМОЩИ" производный от "машина" и от "экстренные службы", класс ПОЖАРНАЯ МАШИНА" производный от "машина" и "экстренные службы" и есть просто "ЛЕГКОВАЯ МАШИНА" от "машина" и "ГРУЗОВИК" от машина.

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

1

Сообщение от vxg пожарная машина - это машина? да. а это служба? нет. значит она не может от нее наследовать. возможно служба должна быть абстрактным полем транспортного средства. или вообще входить в него

Да ты прав я ошибся, там просто сохраняем указатель на "ЭКСТРЕННЫЕ СЛУЖБЫ", потому что наследованием не нужно злоупотреблять, а нужно применять, только если есть логическая цепочка.

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

0

Сообщение от ninja2 Но это ничего не меняет

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

0

Сообщение от vxg меняет. у нас будет абстрактная служба которая делает все что должна делать служба и нам не нужно будет знать конкретику - мы просто будем к ней обращатся

Ну в плане приведение типов не пропадет, нам полюбом нужно определять, токо уже не приводить к служба, а просто по типо "пожарная машина" или "скорая помощь".

0

Сообщение от ninja2 приведение типов не пропадет

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

0