如何动态地创建对象？(一些OOP的东西) - 页 3

新评论
 

BTW，你是否知道Build 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，从我看到的情况来看，它仍然不是针对方法，只是针对函数。

总之，我还是不明白你是如何在基类中定义第三方能力的，例如在趋势线 和容器的背景下，第三对象在哪里。

但我会试着再读一遍。

 
我似乎对与OO和MQL5相关的事件模型 缺乏理解，那就是什么是正确的事件调度方式。
我的意思是，如何和在哪里决定谁（什么类）会得到什么（事件）。
很明显，顶级调度器，即语言的原生调度器，即:OnChartEvent在一个项目中只写了一次，在顶级类中。

那么从这里开始，向不同对象派发事件的正确方式是什么？
是否应该有一个派发事件的类？是否应该仅仅在::OnChartEvent中基于if语句来完成？
 
好的，我想我明白了。当你从程序化到OOP时，确实存在概念转换的问题。
如果我没有理解错，那么你的意思是让CTrendLine通过事件的方式将其价格交叉点通知给CTrade的继承 对象，而不需要知道CTrade的存在，是这样吗？
 
Amir Yacoby:
我似乎对与OO和MQL5相关的事件模型缺乏理解，那就是什么是正确的事件调度方式。
我的意思是，如何和在哪里决定谁（什么类）会得到什么（事件）。
很明显，顶级调度器，即语言的原生调度器，即:OnChartEvent在一个项目中只写了一次，在顶级类中。

那么从这里开始，向不同对象派发事件的正确方式是什么？
是否应该有一个派发事件的类？是否应该仅仅在::OnChartEvent中基于if语句来完成？
这根本就不是问题。OOP是基于自然界的原则的。地球不会养活你，它只是提供资源，而你是否、何时、何地需要什么，则取决于你。
 
Amir Yacoby:
好的，我想我明白了。当你从程序性转为开放性时，确实存在概念转换的问题。
如果我没有理解错，那么你的意思是让CTrendLine通过事件的方式将其价格交叉点通知给CTrade的继承对象，而不需要知道CTrade的存在，是这样吗？
我认为是的。
 
所以实际上现在每个CObject 都有一个对象的位置，这个对象是事件的接收者，也有一个注册方法让监听对象来订阅，还有一个事件发送者方法和接收者使用的事件处理方法。

这很好，它让我想起了观察者模式，只是观察者有多个可能的接收者，m_reciever是一个对象的数组。

事实上，我曾经想实现观察者，但由于MQL中缺乏接口或多继承性，我没有实现。没有想到你的好主意，同一个对象可以在两边强制使用接口。


 
Amir Yacoby:
所以实际上现在每个CObject都有一个对象的位置，这个对象是事件的接收者，也有一个注册方法让监听对象来订阅，还有一个事件发送者方法和接收者使用的事件处理方法。

这很好，它让我想起了观察者模式，只是观察者有多个可能的接收者，m_reciever是一个对象的数组。

事实上，我曾经想实现观察者，但由于MQL中缺乏接口或多继承性，我没有实现。没有想到你的好主意，同一个对象可以在两边强制使用接口。


只是为了鼓励你，我已经在MQL4中经常使用监听器。
 
Ovo Cz:
只是为了鼓励你，我已经在MQL4中使用了很多监听器。

谢谢，但我并不觉得受到鼓励（。

我设法做到了，但不是在发布者和监听器之间签订合同，我的意思是，发布者不得不假设监听器有处理方法，但没有任何东西强迫它有。
或者，我必须从一个主要的监听器对象中继承所有的监听器--但那样我当然会失去所有的意义，因为它们不能继承其他的类。

总之，我是个编程高手，但肯定不是在OO方面，因为我在这方面还缺乏经验，而且我不是在和你们这些有经验的OO程序员竞争，比如Doerk。
我所知道的是，程序化给了你很好的逻辑和编程技巧，但这种转变在精神上是很困难的，特别是如果像我这样的程序化取向的人面对建立OO框架的任务，那是一种完全不同的精神状态。而GUI部分的框架是最详细的框架，有许多事件需要处理，我想你们会同意在框架中它是最难建立的。

12345
新评论