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
E se você não usa aulas, você fica cansado de escrever constantemente algo como SymbolInfoDouble(_Symbol,MODE_BID). Tais danças toda vez - tanto parênteses e sublinhados, e você não sabe se deve pressionar o capslock (e depois em outro lugar sem olhar, digite toda uma corda capitalizada e digite-a novamente) ou manter o shifter pressionado. Pelo menos é aí que o OOP é útil. Se pelo menos criar classes para todas essas funções, então sim - elas são enormes. Se você o escreve por si mesmo, não é um problema. Quanto a trabalhar com pedidos, não há tantas funções usadas com freqüência, podemos simplesmente colocar algumas funções em uma biblioteca. Mas em geral, ainda não foi encontrada uma abordagem ideal.
Aqui está minha visão da classe que pode abrir/fechar/pararar perda e mais tarde exibiro status da ordem
e observe o uso em um símbolo - especialmente uma classe estática para usar
no total, tudo funciona como pretendido.... mas não gosto disso, como escrevi acima é incômodo e supérfluo
E se você não usar aulas, você vai se cansar de escrever constantemente algo como SymbolInfoDouble(_Symbol,SYMBOL_BID). Isto dança cada vez ...
Você poderia fazer embalagens mais convenientes e concisas para estas funções, mantendo-as em estilo de procedimento. Especialmente levando em conta o fato de que em construções recentes eles finalmente adicionaram espaço de nomes, tudo é ótimo. Antes você tinha que implementá-los como métodos estáticos, mas agora tudo é muito mais fácil:
Você pode fazer embalagens mais convenientes e concisas para estas funções, mantendo-se dentro do estilo de procedimento. Especialmente porque finalmente adicionaram espaço de nomes nas últimas construções, isso é ótimo. Antes, você tinha que implementá-las como métodos estáticos, mas agora tudo é muito mais simples:
É realmente importante ficar dentro dos limites? Se for importante ficar dentro dos limites, você pode escrever funções.
bem, não muito, eu diria muitas ações para estabelecer uma ordem, aqui está minha visão para uma classe que sabe como abrir/fechar/estabelecer explosões/e mais status de ordem de saída
e observe o uso em um símbolo - especialmente uma classe estática para usar
no total, tudo funciona como pretendido.... mas não gosto disso, como escrevi acima é incômodo e supérfluo
Sim, aqui está outra pergunta que continua a surgir e que não tem uma resposta inequívoca. Quando você precisar herdar sua própria classe - o que é melhor fazer, herdá-la ou escrever uma nova versão estendida de sua classe.
É possível fazer invólucros mais convenientes e concisos para estas funções, mantendo-se dentro do estilo de procedimento. Especialmente porque finalmente adicionaram espaço de nomes nas últimas construções, isso é ótimo. Antes, era preciso implementá-los como métodos estáticos, agora as coisas são muito mais simples:
Você não tem uma notação sucinta, se não houver cheques, é mais fácil de escrever como está:
e note que para ser usado em um único personagem - especificamente uma classe estática utilizada
Sua entrada não é concisa, se não houver cheques, é mais fácil de escrever como está:
Há muitas funções como SymbolInfoDouble. É um incômodo criar nomes curtos para todos eles. Ao reuni-los em classes, você não precisa se preocupar com a singularidade dos nomes.
Eu tenho o seguinte circuito onde não tive problemas.
sua entrada não é sucinta, se não houver cheques, é mais fácil escrevê-la como ela é:
O que impede que você passe o nome do símbolo ao construtor, tornando a classe flexível e versátil? Você fundamentalmente não considera a possibilidade de negociação de portfólio?
O que impede isso é que, na maioria dos casos, são escritos EAs com um único caractere, e passar um símbolo seria uma ação desnecessária (e exaustiva)). Outra coisa é fazer com que o símbolo do gráfico seja automaticamente selecionado por padrão e, se necessário, você pode substituir o símbolo por um tempo. Mas novamente surge a questão, que é melhor - usar uma instância da classe e substituir o símbolo conforme necessário, ou criar uma instância separada para cada símbolo.