как создавать объекты динамически? (Некоторые вопросы ООП) - страница 3

Новый комментарий
 

BTW, знаете ли вы, что в билде 1325 появились указатели на функции?
Это как-то влияет на применение треугольной связи?

MQL5: Добавлена поддержка указателей на функции для упрощения организации моделей событий.

Чтобы объявить указатель на функцию, укажите тип "указатель на функцию", например:

typedef int (*TFunc)(int,int);

Теперь TFunc - это тип, и можно объявить переменную-указатель на функцию:

TFunc func_ptr;

Переменная func_ptr может хранить адрес функции, чтобы объявить ее позже:

int sub(int x,int y) { return(x-y); }
int add(int x,int y) { return(x+y); }
int neg(int x)       { return(~x);  }

func_ptr=sub;
Print(func_ptr(10,5));

func_ptr=add;
Print(func_ptr(10,5));

func_ptr=neg;           // error: neg is not of  int (int,int) type
Print(func_ptr(10));    // error: there should be two parameters

Указатели на функции можно хранить и передавать в качестве параметров. Вы не можете получить указатель на нестатический метод класса.

 
Я не уверен, что использование указателей функций реализовано и в MT4. Если да, то, конечно, можно сделать и так, при условии, что такими указателями можно управлять и массивами, поскольку это возможно с указателями классов.
 

вероятно, это только для MT5, и из того, что я видел, это все еще не для методов, только для функций.

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

Но я попробую прочитать еще раз.

 
Чего мне, похоже, не хватает в понимании модели событий в сочетании с OO и MQL5, так это правильной диспетчеризации событий.
То есть, как и где решать, кто (какой класс) получит что (событие).
Понятно, что верхний диспетчер, родной для языка, т.е. язык ::OnChartEvent пишется всего один раз в проекте, в классе верхнего уровня.

Тогда отсюда, какой правильный способ или способы диспетчеризации событий к различным объектам?
Должен ли быть класс диспетчеризации событий? Должно ли это быть сделано просто в ::OnChartEvent на основе операторов if?
 
Хорошо, думаю, я понял. Существует реальная проблема смещения понятий, когда вы переходите от процедурного к oop.
Если я правильно вас понял, то вы имеете в виду способ для CTrendLine сообщить о пересечении цены наследующему объекту CTrade посредством события, без необходимости знать о существовании CTrade, верно?
 
Amir Yacoby:
Чего мне, похоже, не хватает в понимании модели событий в сочетании с OO и MQL5, так это правильной диспетчеризации событий.
То есть, как и где решать, кто (какой класс) получит что (событие).
Понятно, что верхний диспетчер, родной для языка, т.е. язык ::OnChartEvent пишется всего один раз в проекте, в классе верхнего уровня.

Тогда отсюда, какой правильный способ или способы диспетчеризации событий к различным объектам?
Должен ли быть класс диспетчеризации событий? Должно ли это быть сделано просто в ::OnChartEvent на основе операторов if?
Это вообще не вопрос. ООП основано на принципах природы. Земля не кормит вас, она просто предоставляет ресурсы, а вы сами решаете, если, когда и где вам что нужно.
 
Amir Yacoby:
Хорошо, думаю, я понял. Существует реальная проблема смещения понятий, когда вы переходите от процедурного к oop.
Если я правильно вас понял, то вы имеете в виду способ для CTrendLine сообщить о пересечении цены наследующему объекту CTrade посредством события, без необходимости знать о существовании CTrade, верно?
Я утверждаю, что да.
 
Так что на самом деле в каждом CObject теперь есть место одному объекту, который является получателем событий, а также есть метод регистрации для слушающего объекта, чтобы подписаться как таковой, и метод отправителя события и метод обработчика события, используемые получателем.

Это здорово, напоминает мне паттерн наблюдателя, только у наблюдателя больше одного возможного получателя, а m_reciever - это массив объектов.

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


 
Amir Yacoby:
Так что на самом деле в каждом CObject теперь есть место одному объекту, который является получателем событий, а также есть метод регистрации для слушающего объекта, чтобы подписаться как таковой, и метод отправителя события и метод обработчика события, используемый получателем.

Это здорово, напоминает мне паттерн наблюдателя, только у наблюдателя больше одного возможного получателя, а m_reciever - это массив объектов.

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


Просто чтобы ободрить вас, я часто использую слушателей в MQL4.
 
Ovo Cz:
Просто чтобы ободрить вас, я много использовал слушателей в MQL4.

Спасибо, но я не чувствую воодушевления (:

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

В любом случае, я профи в программировании, но определенно не в OO, где у меня пока нет опыта, и я не соревнуюсь ни с кем из вас, опытных oo программистов, как Doerk.
Я понял, что процедурное программирование дает хорошие навыки логики и программирования, но ментальный переход очень тяжел, особенно если процедурно ориентированный человек, как я, сталкивается с миссией создания OO-фреймворка, это совершенно другое состояние ума. А фреймворк GUI-части - это самый подробный фреймворк с множеством событий, о которых нужно заботиться, я думаю, вы согласитесь, что среди фреймворков его сложнее всего создавать.

12345
Новый комментарий