como criar objetos de forma dinâmica? (Algumas coisas do OOP) - página 3

Novo comentário
 

BTW, você está ciente de que a construção 1325 introduziu indicadores de funções?
Isso faz alguma diferença na aplicação da comunicação triangular?

MQL5: Acrescentou suporte de ponteiros às funções para simplificar a disposição dos modelos de eventos.

Para declarar um ponteiro para uma função, especifique o tipo "ponteiro para uma função", por exemplo:

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

Agora, TFunc é um tipo, e é possível declarar o ponteiro variável para a função:

TFunc func_ptr;

A variável func_ptr pode armazenar o endereço da função para declará-la posteriormente:

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

Os apontadores para funções podem ser armazenados e passados como parâmetros. Não é possível obter um ponteiro para um método de classe não-estático.

 
Não tenho certeza se o uso de indicadores de função também é implementado com o MT4. Se assim for, claro, também é possível fazê-lo assim, desde que tais ponteiros também possam ser gerenciados por arrays, pois isso é possível com ponteiros de classe.
 

provavelmente é apenas para o MT5, e pelo que vi ainda não é para métodos, apenas funções.

De qualquer forma, ainda não entendo como definir a capacidade de terceiros dentro da classe base, por exemplo, no contexto de linha de tendência e recipiente, onde está o 3º objeto.

Mas vou tentar ler novamente.

 
O que me parece faltar na compreensão do modelo de eventos em conjunto com OO e MQL5, é o que é o tipo certo de envio dos eventos.
Quero dizer, como e onde decidir quem (que classe) vai conseguir o quê (evento).
É claro que o despacho superior, o idioma nativo, ou seja, o idioma ::OnChartEvent é escrito apenas uma vez em um projeto, na classe de nível superior.

Então, a partir daqui, qual é a maneira ou maneiras corretas de despachar eventos para diferentes objetos?
Deve haver uma classe de envio de eventos? Deve ser feito apenas no ::OnChartEvent com base nas declarações de if?
 
ok, eu acho que entendi. Há um problema real de mudança de conceito quando se vem de procedimento para oop.
Se eu acertei, então o que você quer dizer é uma maneira de a CTrendLine informar seu preço cruzado a um objeto herdado da CTrade por meio de evento, sem ter que saber sobre a existência da CTrade, é isso certo?
 
Amir Yacoby:
O que me parece faltar na compreensão do modelo de eventos em conjunto com OO e MQL5, é o que é o tipo certo de envio dos eventos.
Quero dizer, como e onde decidir quem (que classe) vai conseguir o quê (evento).
É claro que o despacho superior, o idioma nativo, ou seja, o idioma ::OnChartEvent é escrito apenas uma vez em um projeto, na classe de nível superior.

Então, a partir daqui, qual é a maneira ou maneiras corretas de despachar eventos para diferentes objetos?
Deve haver uma classe de envio de eventos? Deve ser feito apenas no ::OnChartEvent com base em declarações de if?
Isto não é nenhuma pergunta. O OOP é baseado nos prinicipais da natureza. A terra não alimenta você, apenas fornece os recursos e depende de você se, quando e onde você precisa do quê.
 
Amir Yacoby:
ok, eu acho que entendi. Há um problema real de mudança de conceito quando se vem de procedimento para oop.
Se eu acertei, então o que você quer dizer é uma maneira de a CTrendLine informar seu preço cruzado a um objeto herdado da CTrade por meio de evento, sem ter que saber sobre a existência da CTrade, é isso certo?
Afirmo que sim.
 
Assim, na verdade cada CObjeto agora tem um lugar de um objeto que é o receptor de eventos, e também tem um método de registro para que o objeto de escuta se inscreva como tal e um método de remetente de eventos e um método de manipulador de eventos usado pelo receptor.

Isto é bonito, me lembra o padrão do observador, somente com observador tem mais de um possível receptor, o m_reciever é um conjunto de objetos.

Na verdade, uma vez quis implementar o observador e por falta de interfaces em MQL ou herança múltipla não o fiz. Não pensei em sua boa idéia de que o mesmo objeto pode forçar a interface de ambos os lados.


 
Amir Yacoby:
Assim, na verdade cada CObjeto agora tem um lugar de um objeto que é o receptor de eventos, e também tem um método de registro para que o objeto de escuta se inscreva como tal e um método de remetente de eventos e um método de manipulador de eventos usado pelo receptor.

Isto é bonito, me lembra o padrão do observador, somente com observador tem mais de um possível receptor, o m_reciever é um conjunto de objetos.

Na verdade, uma vez quis implementar o observador e por falta de interfaces em MQL ou herança múltipla não o fiz. Não pensei em sua boa idéia de que o mesmo objeto pode forçar a interface de ambos os lados.


Só para encorajá-los, tenho usado muito os ouvintes com a MQL4.
 
Ovo Cz:
Só para encorajá-lo, tenho usado muito ouvintes com a MQL4.

Obrigado, mas não estou me sentindo encorajado (:

Consegui fazê-lo, mas não com um contrato entre a editora e o ouvinte, quero dizer, a editora teve que assumir que o ouvinte tem o método de manuseio, mas nada forçado que ele tenha.
Ou, eu teria que herdar todos os ouvintes de um objeto principal do ouvinte - mas então, é claro, eu perderia todo o sentido porque eles não podem herdar outras classes.

De qualquer forma, eu sou um profissional em programação, mas definitivamente não em OO onde ainda não tenho experiência, e não estou competindo com nenhum de vocês programadores experientes como Doerk.
O que eu sei é que ser procedural dá a vocês boa lógica e habilidades de programação, mas a mudança é mentalmente difícil, especialmente se um programador de procedimentos como eu enfrenta a missão de construir uma estrutura OO, é um estado de espírito totalmente diferente. E a estrutura da parte GUI é a estrutura mais detalhada com muitos eventos para cuidar, eu acho que vocês concordarão que entre as estruturas é a mais difícil de construir.

12345
Novo comentário
Razão: