Sobretaxa para a OLP - página 4
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Minha experiência mostra que você precisa fazê-lo.
Fui por aqui há cerca de cinco anos, na época, no MT4. (Não porque eu não soubesse do OOP, mas porque eu era preguiçoso demais para me preocupar com interfaces e herança, especialmente porque naquela época o MT4 e o MT5 eram significativamente diferentes em termos de implementação do MQL). Isto me levou à compreensão de sua falácia. Isto não é "sabedoria", mas uma limitação razoável, uma espécie de "infalível". Se você sempre se lembra do que cada uma de centenas de variáveis é responsável - você não precisa de encapsulamento. Não me lembro disso, e prefiro ter o mínimo possível de entidades disponíveis em cada bloco de um programa.
Assim que a MQL4 apareceu OOP - comecei a traduzir todos os meus desenvolvimentos em uma única forma baseada em interfaces.
Eu ainda não consegui encontrar nada mais conveniente do que o sistema de pedidos MQL4. Se você tem um exemplo, por favor, mostre-me.
Todas as API comerciais que vi parecem monstruosas em comparação com a MQL4. Eles também são desajeitados.
Nunca fui capaz de inventar nada mais conveniente do que um sistema de pedidos MQL4. Se você tem um exemplo, por favor, mostre-me.
Todas as API comerciais que vi parecem monstruosas em comparação com a MQL4. E mais ainda, são desajeitadas.
De que servirá isso, cada parâmetro deve ser desenhado em uma função separada. Seria mais lógico receber a estrutura com todos os parâmetros por solicitação, como com carrapatos.
Nunca consegui inventar nada mais conveniente do que um sistema de pedidos MQL4. Se você tem um exemplo, por favor, mostre-me.
Todas as API comerciais que vi parecem monstruosas em comparação com a MQL4. E mais ainda, são desajeitadas.
O que você quer dizer?
A própria essência dos pedidos ? Sim, eu concordo, é bastante útil.
Mas apenas a aplicação do OOP a este sistema, em minha opinião, é o que dá a maior "vitória". Digamos que eu tenho a mesma interface - dá tanto a posição MT4 que consiste em ordens e a posição MT5 que consiste em posições MT5, e independentemente das condições de hedging ou netting.
Na minha opinião, é muito mais lógico e compreensível quando temos uma lista de objetos de ordem (ou posições MT5) obtida através da função Select() e nos dirigimos às propriedades das ordens, ao invés do"estado do ambiente" (obtido através da mesma função), que abordamos através de funções.
O mais interessante é se precisarmos rastrear várias ordens ao mesmo tempo - neste caso, a abordagem processual inevitavelmente leva à abordagem "pseudo-objeto" - temos que criar uma série de informações sobre ordens que devem ser atualizadas ao entrar no OnTick() e trabalhar com dados de ordem por índices na série, assim como com os indicadores OOP para pedir objetos.
Além disso, a abordagem OOP nos daria uma vantagem ao trabalhar com ordens históricas e ativas simultaneamente, já que a interface da ordem histórica é o sucessor da ordem ativa. E a abordagem processual significa que as ordens históricas e ativas são tratadas por diferentes funções, o que é muito menos conveniente.
O que é bom é que cada parâmetro tem que ser puxado por uma função separada. Seria lógico obter a estrutura com todos os parâmetros sob solicitação, assim como com carrapatos.
As entradas Order.TakeProfit e OrderTakeProfit() são as mesmas. O primeiro tem apenas a possibilidade de armazenar o objeto, e o segundo - relevância. A necessidade de armazenagem é atendida muito raramente, e não em TS. E aí não há problema em criar a estrutura.
Eu mesmo me perguntei por que os desenvolvedores não fizeram o retorno da estrutura do pedido e deixaram cada campo separadamente através de uma função (pois o histórico também requer um bilhete a cada vez).
Em geral, não vejo nada de realmente errado com a MQL4-API (pode funcionar não apenas em MT4/5).
O que você quer dizer com isso?
A própria essência do comércio de pedidos ? Sim, eu concordo, bastante útil.
Mas apenas a aplicação do OOP a este sistema - na minha opinião - é o que dá a maior "vitória". Digamos que eu tenho a mesma interface - dá tanto a posição MT4 que consiste em ordens e a posição MT5 que consiste em posições MT5, e independentemente de ser coberta ou compensada.
Você tem seu próprio embrulho, o outro tem seu próprio embrulho. A questão era se é possível criar uma embalagem mais conveniente do que a MQL4.
É muito mais lógico e compreensível em minha opinião, quando temos uma lista de objetos de ordem (ou posições MT5) obtida usando a função Select() e acessamos propriedades de ordem em vez de"estado do ambiente" (obtido usando a mesma função) que acessamos através de funções.
O mais interessante é se precisarmos rastrear várias ordens ao mesmo tempo - neste caso, a abordagem processual inevitavelmente leva à abordagem "pseudo-objeto" - precisamos criar uma série de informações sobre ordens que devem ser atualizadas ao entrar OnTick() e trabalhar com dados de ordem por índices na série, da mesma forma que com OOP-pointers para pedir objetos.
Eu escrevi sobre isso no post anterior.
Além disso, a abordagem OOP nos daria uma vantagem ao trabalhar com ordens históricas e ativas simultaneamente - uma vez que a interface da ordem histórica é herdeira da ordem ativa. A maioria das funções são comuns. E a abordagem processual nos permite lidar com ordens históricas e ativas usando diferentes funções, o que é muito menos conveniente.
Bem, na MQL4, a história é tratada pelas mesmas funções (OrderHistoryTotal não conta).
Seria bom ter um exemplo de código onde a própria API comercial é claramente melhor do que a MQL4-API. Eu mesmo uso OOP em quase todos os lugares. E para algumas tarefas específicas eu faço algumas embalagens comerciais. Mas eles não são universais, embora sejam muito convenientes de usar para alguma tarefa em particular. Entretanto, eu ainda quero comparar as APIs comerciais universais.
Eu mesmo me perguntei por que os desenvolvedores não fizeram da devolução da ordem uma estrutura, mas deixaram cada campo individualmente através de uma função (um ticket também é necessário cada vez para a história).
Alexey Volchanskiy:
Дело в том, что в МТ4 до 600-го билда не было структур )) А новый MQL4 появился где-то в начале 2013 г.
Na MT5 havia estruturas, mas retornos através de funções ainda.
Fórum sobre comércio, sistemas automatizados de comércio e testes estratégicos
Sobretaxa para o OOP
fxsaber, 2017.07.07 08:08
A questão era diferente, é possível criar uma embalagem mais conveniente do que a MQL4?
No MT5 havia estruturas, mas de qualquer forma retornavam através de funções.
Talvez eles tenham decidido não quebrar a tradição, mas deveriam tê-lo feito.
Entendo que se os dados fossem baixados do servidor da corretora, mas são locais, são pegos instantaneamente, você poderia preencher a estrutura imediatamente
Eles provavelmente decidiram não quebrar a tradição, embora devessem ter
Entendo que se os dados fossem baixados do servidor DC, mas eles são locais, são tomados instantaneamente, você poderia preencher a estrutura imediatamente
Sim, durante o SELECT nós apenas preenchemos uma instância de uma estrutura oculta, cujos campos só podem ser acessados através das funções const(read-only)-funções.
Esta é provavelmente a única solução central questionável do API comercial. Caso contrário, eu nem sei do que reclamar.
Sim, quando o SELECT é utilizado, ele preenche uma instância de uma estrutura oculta cujos campos só podem ser acessados através de funções const(read-only)-funções.