Pedido inválido - apenas começou e não se consegue perceber... - página 6

 
-Alexey-:

Porquê, escrevi um para mim, mas para quatro.

Então, escreveu pessoalmente uma biblioteca universal, separada da lógica empresarial da EA e que pode ser utilizada em qualquer EA?

Eu também não acredito nisso. É claro que o código de resposta do servidor estava lá, mas tudo dentro da lógica empresarial, não como uma biblioteca universal.

 
Renat:

Então escreveu pessoalmente uma biblioteca universal, separada da lógica empresarial da EA e que pode ser utilizada em qualquer EA?

Eu também não acredito nisso. É claro que o código de resposta do servidor estava lá, mas tudo dentro da lógica empresarial, não como uma biblioteca universal.

Sim, eu posso prová-lo. Por uma certa quantia de dinheiro, é claro.
 
-Alexey-:
Sim, eu posso prová-lo. Por um preço, é claro.

Também não há biblioteca para o MT4.

Não foi assim tão difícil de provar.

 
Renat:

Ou seja, também não há biblioteca para o MT4.

Não foi assim tão difícil de provar.

Ou seja, existe de facto. Após a transferência de dinheiro, este ser-lhe-á fornecido agora mesmo. Mas não o tem nem para 4 nem para 5.
 
Renat:

Renat, tenho a sensação de que a utilização da biblioteca padrão cai sob o refrão: "OOP ou não OOP".

Caso contrário, não consigo compreender porque é que as pessoas têm fortes convicções de que um invólucro OOP, que simplifica as operações comerciais, não deve ser utilizado.

Alguns reclamam um invólucro para fazer toda a lógica, lidar com erros, repetir consultas, etc. E ao mesmo tempo a sua utilização é supostamente perigosa e há um erro em cada linha...

 
-Alexey-:
Isto é, está lá.

não o tem. todos os erros são tratados pela lógica empresarial.
Utiliza a propriedade de sincronicidade no MT4, o que simplifica o processamento até certo ponto, mas os seus métodos não garantem 100% de todos os casos. Provavelmente 95% e isso é apenas a sua bíblia na qual todo o processo comercial se baseia.
Mas o MT5 é muitas vezes mais complexo em termos de tratamento de códigos de retorno + assíncrono.

Está a pedir o impossível de um invólucro. A biblioteca padrão não é lógica empresarial. É um invólucro "sobre" as funções do terminal. Um invólucro sobre o recheio de uma barra de chocolate.
É uma interface de fácil utilização que assume parte da rotina. Assumir o mesmo tipo de código. Não se come um invólucro de papel e queixa-se porque é que não é comestível. :)

Mas o invólucro não pode garantir nada, uma vez que é você que actua como fiador. A sua lógica empresarial. :)
Tal como a função Imprimir não pode garantir espaço livre no disco e erros de registo. É necessário utilizar outras funções para o tratamento de erros e elas são específicas para cada caso.


-Alexey-, vamos conversar sobre falhas específicas e você fala sobre as falhas específicas que gostaria de corrigir.

Se quiser, pode percorrer cada código de retorno e ver as principais situações possíveis.

 
papaklass:


Responder às perguntas:
- porque arrastaria todos estes 61 métodos para trás de mim? É racional?

A questão vai no plano de saber se precisa ou não de programação OOP. Não posso responder-lhe sem ambiguidade.
Na minha prática utilizo o OOP para modelos de alto nível.
Claro, utilizo-o muito na minha base apenas nas funções.

De forma correspondente, quando utilizo uma classe OOP, contém muitas coisas desnecessárias para alguma tarefa em particular. É como a funcionalidade da biblioteca de desenho kanvas. Há linhas e quadrados e texto. Mas não há nada a discutir - se esta classe deve ter um quadrado ou não. Está mesmo ali. Para uma determinada tarefa.


Há demasiados problemas que estão a tentar resolver dentro de uma única classe.

está enganado. Eles não estão a resolver nenhum problema. enrolaram-se à volta da RUTINA. é difícil de compreender.


Consequentemente, o tratamento de erros deve ser para todas as tarefas a serem resolvidas.

Não pode estar lá. Uma vez que a bíblia não resolve nenhum problema. Simplifica o RUTINO. É tudo. Não pode fazer mais, e não precisa de ser complicado.

A solução é suficientemente simples: dividir uma classe incómoda em várias mais pequenas, de acordo com os problemas a serem resolvidos:
Neste caso, envolverei apenas as classes que se enquadram na minha estratégia e nada supérfluo. E será muito mais fácil de implementar o tratamento de erros do que é agora.

Bem, não é uma rotina de embrulho. Já é um solucionador de problemas com a lógica específica do SEU perito.
Não se pode prever o tratamento de erros mesmo numa única função - abrir ou fechar. 1001 casos são sempre encontrados, quando os erros previstos não se encaixam e é necessário fazer outra coisa.

Se conhece uma função universal para todas as situações, por favor mostre-a. Não consigo sequer imaginar como é possível prever com antecedência todo o tratamento de erros possíveis, sem conhecer a lógica de uma determinada EA.
Mesmo que eu faça tal função - contradiz todas as suas palavras mais elevadas - "voltou a fazer demasiado barulho".

E se aplicar o seu método de escrita de código através de macros com direcção (ORDER_TYPE_BUY / ORDER_TYPE_SELL), então as classes serão bastante compactas.
Onde está tudo isto?

Mas as macros também não têm tratamento de erros. São tratadas pela lógica comercial de um Expert Advisor em particular num determinado erro. Não é assim tão difícil de compreender que não existem situações universais.

Se Renat aprendesse a ouvir as sugestões do fórum e tentasse compreender o significado destas sugestões, o MT5 já estaria muito à frente do que está hoje nesta fase de desenvolvimento.

Renat continua a repetir - estamos num fórum técnico. Não podemos falar aqui de coisas abstractas.

Por isso, por favor, dê-nos algumas especificações. Vamos considerar os termos de referência, as funções comerciais de que necessita e os possíveis erros e como lidar com eles. ok?

 
papaklass:

Responder às perguntas:

- se preciso apenas de colocar uma ordem de mercado, ou uma ordem pendente, porque arrastaria todos esses 61 métodos atrás de mim? É racional?

- Se eu tenho uma posição aberta e preciso apenas de definir paragens, porque é que eu arrastaria toda essa funcionalidade com 61 métodos? É racional?

- Se tenho uma posição aberta com paragens que serão activadas quando o preço atingir o seu nível, porque devo arrastar todos estes 61 métodos? É racional?

Ninguém o está a proibir:

  1. Não utilize soluções prontas na forma de bibliotecas já escritas por outra pessoa, mas escreva o seu próprio código a partir do zero.
  2. Reescrever uma biblioteca já preparada sob a forma de classes modificadas, retirando dela os métodos que na sua opinião são "supérfluos".
  3. Métodos de substituição a partir de uma biblioteca pronta a usar, por herança
 
papaklass:

Qual é o objectivo de "separar as operações de comércio em diferentes classes".

É o mesmo como se tivesse diferentes EAs para abrir, fechar e modificar. Parece ser possível, mas ninguém o faz (com raras excepções, tarefas especiais).

E gosto muito da frase "se preciso apenas de colocar uma ordem de mercado ou uma ordem pendente, porque é que eu deveria arrastar todos esses 61 métodos comigo? Isso é racional"?

Haverá cerca de 100kb de despesas gerais de memória por Expert Advisor. Caramba...


A propósito, aqui está uma sondagem. Utiliza a biblioteca padrão para operações comerciais?

 
papaklass:

Francamente, eu não devia ter saído com o meu posto.

Não por nada, percebi que não sou o único que não é convencional :) Na sondagem - prestei a minha homenagem