LINUX.ORG.RU

О наследовании и вызове методов.

 


0

3

Я привык, что в ОО языках если есть:

  • Класс A
  • В классе A определён метод action()
  • Есть класс B наследующий от A

, то я могу вызывать метод action() для экземпляров B. Другими словами, если возможно A.action() и B::A, то возможно B.action().

А если я использую GObject, то это так или нет?

Пусть у нас есть

typedef _MamanBar MamanBar;
typedef _SonBar SonBar;

struct _MamanBar
{
GObject parent_instance;
};

struct _SonBar
{
MamanBar parent_instance;
};

void maman_bar_action (MamanBar *self)

Я ведь не могу вызывать

SonBar *son;
/* */
maman_bar_action (son);
Так? Нужно ведь вызывать
SonBar *son;
/* */
maman_bar_action (MAMAN_BAR (son));

Получается, что мне чтобы вызывать метод недостаточно знать, что он был определён в родительском классе, но точно знать, что в каком из классов иерархии наследования он был определён. Это так?

Помимо того что это лишняя головная боль, не является ли это нарушением принципов ООП?

Или я что-то делаю не так?

★★★★★

Это так?

Да

не является ли это нарушением принципов ООП?

Возможно, мне это как-то безразлично. Те, кто хотят чистого ООП, пишут на Smalltalk. Только их немного почему-то

Gvidon ★★★★ ()
Последнее исправление: Gvidon (всего исправлений: 1)

Тебя смущает MAMAN_BAR, но не смущает maman_bar_action?

baverman ★★★ ()

А если я использую GObject, то это так или нет?

Это не вопрос GObject, это вопрос ЯП.
На vala отлично работает son.action, т.ч. просто use vala.

Тебя смущает MAMAN_BAR, но не смущает maman_bar_action?

+ 1 к вопросу этого господина

Tayler ★★ ()

Если хочется общности, можно вместо MAMAN_BAR (son) сделать (void *)son. Указатели на void в C могут неявно приводится к указателю на любой тип. Правда, если окажется, что son всё-таки не наследует от MamanBar, словишь лулзов

Gvidon ★★★★ ()
Последнее исправление: Gvidon (всего исправлений: 1)

Не надо писать руками то, что лучше генерировать. Для gobject используй vala. Чистому С нет места. Особенно в нише десктопа.

anonymous ()

Ты не так выбираешь язык. В си нет ООП. GObject - это библиотека для универсального ООП, предназначенная для создания нативного кроссязыкового ОО-окружения. Писать код для него именно на С не обязательно и даже вредно(ибо слишком много копипасты, деревьев, за которыми не видно леса и пр.). Так что бери свой любимый язык, который бы имел интеграцию с glib и вперед. Vala тут уже советовали(ее же советуют и сами G*'ные разработчики).

А для имитации ООП в С можно действовать проще и построить более простую модель, не требующую столько копипасты.

anonymous ()
Ответ на: комментарий от anonymous

vala - мертворождённая какашка. Лучше уж C++ + glibmm заюзать, чем это.

anonymous ()

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

KblCb ★★★★★ ()
Ответ на: комментарий от Gvidon

А как в GObject реализовано динамическое связывание?

KblCb ★★★★★ ()

Помимо того что это лишняя головная боль, не является ли это нарушением принципов ООП?

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

если вы про принципы ооп (в С++ где порядок лексического выяснения какой же статический метод подразумевается в случае отсутствия такого непосредственно у типа(класса) самой переменной) - то очевидно нарушение.

если вы про принципы обьектного_программирования от Алана Кея — то неа.

либо кури Страустропа либо перелазь на валу.

оба варианта не настолько фундаментальны, что бы на них строить вероисповедания как любят делать мало....

принципы ооп - это блин маркетинг головного мозга - ещё бы принцип крышки унитаза пропагандировали.

qulinxao ★★☆ ()
Ответ на: комментарий от KblCb

Через указатели на функции, которые для разных типов указывают на разные функции. Т.е. есть у всех GObject'ов есть указатели на функции finalize, constructor и так далее, но при создании объектов производных типов они выставляются на соответствующие функции. Это если в двух словах

Gvidon ★★★★ ()

Или я что-то делаю не так?

Ну если _очень_ хочется, то можно

struct _MamanBar
{
GObject parent_instance;
int (*action)(void *obj);
};

son->action(son);
monk ★★★★★ ()

возьми лучше спп и кьют.

anonymous ()
Ответ на: комментарий от Tayler

Use Vala.

А как с GStreamer'ом? С одной стороны биндинги только для gstreamer-0.10, а с другой элементы GStreamer'а являются наследниками GObject. Можно ли писать на Vala программу использующую GStreamer-1.0 без вставок на C (или с минимальными вставками). Секаса много ли в таком случае?

Camel ★★★★★ ()
Ответ на: Use Vala. от Camel

С одной стороны биндинги только для gstreamer-0.10

В Vala-0.18 для 1.0 есть.

-rw-r--r-- 1 root root 137K дек.  19 14:11 /usr/share/vala-0.18/vapi/gstreamer-1.0.vapi

без вставок на C (или с минимальными вставками)

Вместо вставок используются vapi-файлы, описывающие интерфейс библиотеки. Вставки бы только нарушили все концепции ООП и сделали бы код небезопасным.

backbone ★★★★★ ()
Ответ на: комментарий от backbone

То что надо.

Да, Vala с привязками к GStreamer-1.0 это то что надо.

Camel ★★★★★ ()
Ответ на: То что надо. от Camel

То что надо.

Да, спп с кьютишным qmediaplayer это то что надо.

//fxd

anonymous ()

головная боль

нарушением принципов ООП

Хорошу вещь ГОбжект не назовут :)

slackwarrior ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.