kexman Если ты словами можешь сформулировать, что "племянник" меньше "дяди", то почему не можешь записать это на алгоритмическом языке? Ну, а не надо, так и не надо...

Билли Бонс
Не буду грузить ньюансами программы. Я просто был очень рад, что все так легко разрешилось)

Вопрос:
Определил в программе базовый класс MObject, от которого я наследуюсь. Объектов базового класса не существует в программе.
Все дочерние классы также наследуются плюс ко всему от еще одного класса - GraphicsItem:

Далее в MObject есть один метод, который должен обратиться к методу объекта, унаследованного от GraphicsItem. Как это можно сделать? Ведь сам MObject не знает такого метода. Пользовался операторами преобразования типов(static_cast, const_cast), нифига не получилось:

Можно ли как-нибудь это сделать?

Естественно, есть такой паттерн, Template Method называется, если вкратце:

Daemon
Просто это как-то не в стиле ООП получается, в каждом наследнике я должен писать один и тот же код. А так я хотел, чтобы он исполнялся в MObject, и все его наследовали.

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

Можно использовать аксесор, можно паттерн Command, можно наконец плюнуть на все и использовать dynamic_cast (а не const_cast)
Кстати, что-то мне подсказывает, что ты опять пытаешься изобрести Visitor, как и пару страниц назад.

Daemon

Но ведь GraphicsItem не является потомком MObject.
Может ты недопонял меня, еще раз попробую объяснить. Все объекты являются потомками MObject и GraphicsItem. Мне нужно из метода MObject::SetData вызвать метод GraphicsItem::SetVisible() для "себя", то есть поскольку объект гарантированно(по логике программы) является потомком GraphicsItem, то к нему можно применить этот метод. Но внутри MObjecta к указателю this нельзя его применить, вот я и хотле как-нибудь перевести MObject *this в GraphicsItem*.
Добавлено спустя 1 минуту, 27 секунд
А может я не понял тебя: Command, Visitor и аксессоры?? Знаю только, что Command применяется для реализации волшебной кнопочки undo.

kexman ага, слона-то я и не приметил, сейчас подумаю.
Добавлено спустя 5 минут, 32 секунды
Ну короче говоря, я вот подумал и решил, что оптимальнее будет зделать так:


Эдакая смесь Template Method + элементы Adapter'а

Daemon
Ага в принципе это то что нужно. Но есть 1 маленький ньюанс - GraphicsItem, а точнее QGraphicsItem - стандартный класс библиотеки QT, он также является абстрактным, базовым классом, у него в библиотеке реализовано множество потомков. И фактически мне надо наследоваться от потомков, а не от него, то есть я хотел так:

То есть в библиотеке QT, классы QGraphicsSimpleTextItem, QGraphicsEllipseItem, QGraphicsRectItem наследованы от QGraphicsItem. И тое есть если я унаследую FiguresBase от GraphicsItem, то потомки, которые я только что объявил будут иметь предка QGraphicsItem по обеим линиям, так как например для TextItem:
и FiguresBase и QGraphicsSimpleTextItem имеют предка QGraphicsItem. То есть у меня смешиваются 2 иерархии классов, хочу грамотно это дело разрулить. Так понял, в этих случаях используют виртуальное наследование, но в QT эти классы наследованы от базового невиртуально, поэтому вариант отпадает. Или все-таки придется делать виртуальную функцию в MObject, и реализовывать ее в каждом дочернем классе.

Епт, прям Болливуд какой-то, я твой брат, ты мой сестра и т.д.
Делаем так:


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

Daemon
ОО, круто!!! Я бы честно говоря даже и не догадался бы, вообще клевое решение!

Daemon
Читаю сейчас на досуге про C#, интересно почему нельзя также ввести в стандарт C++ те же самые свойства? Это же удобно. Плюс еще почитаю про интерфейсы - что это такое, и чем отличается от множественного наследования.
Какое у C# преимущество, как я понимаю, его разрабатывали, не ставя себе цель обеспечить совместимость с каким-либо языком прошлого поколения, а пыталиь брать лучшее из каждого языка.

Свойства - с одной стороны удобно, а с другой стороны не очень. Потом попробуй разобрать, это обращение к члену класса или к свойству, запутывает. Хотя конечно с этим должна справляется IDE, но VS увы пока этого не имеет. А касательно интерфейсов и множественного наследования, да не помешало бы кое-что поменять. Но с другой стороны, уже столько кода написано, и множественное наследование компенсирует отсутствие интерфейсов.

Это все субъективно. Над C# работал человек, который в свое время работал над Delphi, и такое впечатление, что шарп от-туда много подчерпнул, те же свойства. Я на досуге читаю Python.

Daemon
Ну этот же человек в свое время написал turbo pascal - знаковая вещь как мне кажется. http://ru.wikipedia.org/wiki/Turbo_Pascal . Кто не использовал турбо паскаль? Я даже определенную симпатию к нему испытываю сейчас
Думаю тоже какой-нибудь прикольный язык начать осваивать, типа Python или Hascell(не знаю как пишется). Думаю интересно.
Вопрос есть, как к профессионалу, можно ли научиться программированию, не имея специального образования? Я вот кроме в школе и первых двух курсов в универе учился совсем не связанным с программированием вещам. Что для этого нужно? Сейчас пишу алгоритм, построения линий равных высот, по сетке(матрице) данных. Имею исходники реализации этого в другой программе, так там 550 строк, против моих 170. Вот и думаю, в каком направлении двигаться, что изучать. Математику? Если да то какой ее раздел? Или еще что-то? Кнута штудировать? ООП - это ведь только одна сторона. А ведь еще есть технологии всякие, их полно, хотя мне для прикладухи может и не понадобиться.
Добавлено спустя 33 минуты, 23 секунды
короче ходил в 2 магазина. По проектированию книг нет.
Очень понравилась книжка по С++ нашего автора, тоненькая такая, страниц 200-250. Называется Самоучитель с++. На обложке написано, привожу почти дословно:

Я в шоке был

Есть класс:
class sc
{
private:
int i;
public:
operator int (){return i;}
operator char (){return 'r';}
};
Как избежать ambiguity если нужно и преобразование и в инт и в чар?

>>почему нельзя также ввести в стандарт C++ те же самые свойства? Это же удобно.

Использую свойства только тогда, когда нужно пользователю предоставить интерфейс для настройки в VS IDE. Явные методы (а CLR не знает про свойства, такое понятие существует только на уровне метаданных, которые объединяют два метода get_*** и set_*** в единую сущность) обеспечивают лучшую читаемость и понимание, что вызывается именно метод (т.е. это все не бесплатно, а то находятся товарищи, которые не кэшируют значение свойства и вызывают тяжелые операции по несколько раз в одном куске кода, хотя значение при этом не изменяется).

>>чем отличается от множественного наследования.

В C# различают два вида наследования: наследование реализации и наследование контракта. В принципе роль интерфейса может выполнять и абстрактный класс, но т.к. CLR не поддерживает множественного наследования для классов (и правильно), то ввели понятие интерфейса (в принципе, это тоже класс - CLR [не C#] даже позволяет использовать для него конструктор, но он "равнее", чем остальные).

>>По проектированию книг нет.

Зато в интернете навалом Особенно на английском.

>>Я в шоке был

Вполне себе нормальное описание. C++ без STL - реально в 250 страниц уместить при этом демонстрируя основы ООП.

>>Кнута штудировать?

Есть такая замечательная книга "Алгоритмы на С++". Много понятнее Кнута. К тому же готовые реализации на C++ имеются.

>>Как избежать ambiguity если нужно и преобразование и в инт и в чар?

А ты каким компилятором компилируешь? У меня VC++ 2005. Неоднозначностей нету. В любом случае можешь попробовать создать методы типа ToInt() и ToChar().