Mt4 Fim do apoio. - página 28
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
Não sei se alguém o sugeriu, mas por que não mudar tudo no MT4 para o MT5, então todos seguiriam em frente.
George Merts:
Eles escrevem as partes primeiro e depois as combinam em um todo, muitas vezes descobrindo que as partes não são compatíveis entre si - o que, aliás, é o que explica o desejo de "ter acesso a todas as variáveis disponíveis".
Não, não é. Não se trata de ter acesso a todas as variáveis possíveis, apenas àquelas que você precisa. Estas são geralmente variáveis de entrada e saída de diferentes funções.
Adicionar limites adicionais aqui tornará imediatamente a legibilidade do código muito mais difícil e aumentará os possíveis erros quando algo não chegou lá porque se perdeu no caminho por causa desses limites.
Certamente compreensível o desejo de, pelo menos de alguma forma, retirar o OOP para algo útil, mas tais casos geralmente não se encontram no campo da programação, mas na esfera comercial, por exemplo, para horas extras de programação, criação de discussões intermináveis sobre a arquitetura das interfaces e o agradável passatempo no tempo de trabalho.
Existe, em princípio, um exemplo disso? Mesmo que não seja seu? Tenho profundas dúvidas. No início dos dois milésimos de anos deixei de contar o número de linhas de depuração e de trabalho do código do programa escrito por mim porque excedeu um milhão - tornou-se desinteressante. E nunca encontrei a necessidade de criar minha própria classe, embora a variedade e a escala das minhas tarefas fossem muito diversas. Tive que usar variáveis do tipo procedimento quando foi necessário paralelizar o trabalho para várias pessoas, mas não mais. Por que isto é assim?
A questão é que o OOP só pode ser aplicado à embalagem do código pronto e só o impede na fase de escrita do código. Mas se não há tal necessidade, você também não precisa de OOP.
Vladimir:
Acontece que o OOP impede o paralelismo automático dos cálculos. Hoje em dia deve ser considerado como um inconveniente muito sério, a perspectiva não é para o OOP.
A perspectiva está em idiomas como Systemverilog.
Tudo bem, exceto pelo fato de que a função isNewBar() não deveria existir de forma alguma. É engraçado que há tanta dança em torno de uma coisa tão trivial.
É apenas uma variável, e é simplesmente comparada ao tempo da barra; se todos os casos tiverem sucesso, então a variável é atribuída ao tempo da nova barra no final. Caso contrário, apenas uma tentativa é atribuída a todos os casos.
Adicionar limites adicionais aqui tornará imediatamente a legibilidade do código muito mais difícil e aumentará os possíveis erros quando algo não chegou a algum lugar porque se perdeu no caminho por causa desses limites.
É exatamente o oposto - os limites permitem que você não pense "para que serve esta variável, que papel ela desempenha neste caso, não deveria ser levada em conta".
O usuário tem acesso apenas ao que precisa considerar, e apenas ao que pode mudar. Estes são os próprios erros "quando algo se perde pelo caminho" - e surgem precisamente porque há muita coisa disponível e algo é "esquecido pelo caminho". Com interesses virtuais "truncados", isto é muito mais difícil de fazer.
Aqui está o exemplo mais simples: ganhar uma posição. Uma posição é ou ordens em aberto no MT4 ou posições em aberto no MT5.
Se você tem acesso total, então ao selecionar uma posição - o usuário tem que lembrar quais variáveis podem ser lidas agora, quais variáveis são inválidas no momento, quais variáveis ele pode mudar, e quais não são.
Com a interface, as coisas são muito mais simples. Você o tem, e há apenas duas funções nele: obter o número de componentes, e obter um ponteiro para um componente constante. É ISTO. Com estas duas funções - você não pode ter acesso físico a nenhuma "variável extra".
Andrei:
É claro que compreendo o desejo de, pelo menos de alguma forma, arrastar o OOP para algo útil, mas tais casos geralmente não se encontram no campo da programação, mas na esfera comercial, como horas extras de programação, discussões intermináveis sobre a arquitetura das interfaces e o agradável passatempo em horas de escritório.
E você chegará a isso mais cedo ou mais tarde. Além disso, o encapsulamento pode ser feito em uma abordagem "puramente processual". Mas é mais conveniente na abordagem OOP, porque você ainda recebe a herança e o polimorfismo "automaticamente".
Não sei se alguém o sugeriu, mas por que não mudar tudo no MT4 para o MT5, então todos seguiriam em frente.
O problema não é apenas que há algo em 4 que não está em 5. E não é nem mesmo o OOP.
5 não deu praticamente nada aos comerciantes (não programadores, não comerciantes de software - apenas comerciantes).
Formato próprio de histórico, proibição de costumes - mas estes dois pontos afugentaram todos os que comercializam geometria. E não há "muitos TFs" (sem balanças anuais, rs), escalas em pips por barra os atrairão.
Uma pergunta simples. O que a "grade" mostra? Tentar descobrir levará você à recomendação de ir ao freelancer e encomendar o que você quiser.
As MTs são terminais para programadores. Essa é a resposta completa.
A questão é que o OOP só pode ser aplicável à embalagem de código pronto, em uma etapa da escrita do código ele só interfere. Mas se não há tal necessidade, não há necessidade no OOP.
Não, não é. É exatamente o contrário.
As interfaces são definidas inicialmente, mesmo "antes da fase de escrita do código". As interfaces são, de fato, todas os mesmos ToR para o programador. Todas as interações no Freelance são realizadas exatamente com o uso de um ToR claro. Portanto, as interfaces virtuais são uma espécie de TOR, que é onde a programação começa.
Você apenas, como eu entendo, está se aproximando da própria essência do OOP de forma incorreta. Primeiro você escreve um monte de funções e depois você tem que "espremê-las" no projeto OOP. Mas este é um caminho errado. O caminho correto é o oposto - primeiro você define OOP-definition, esses conjuntos de interfaces básicas entre os componentes do sistema. E então, um por um, cada componente é escrito seguindo estas interfaces muito pré-definidas.
Sim, às vezes acontece de descobrirmos ao escrevermos o código que a interface não forneceu algo. E então você começa... "Ohhhh... Na abordagem processual - eu teria acesso a tudo isso, não teria problemas em fazer o que preciso, mas agora - como ter acesso a essas variáveis". Isto acontece quando na fase de projeto das interfaces - algo não foi levado em conta. Esta é uma situação muito desagradável - ou você tem que adicionar algumas interfaces adicionais, ou mudar as existentes - que está repleta de erros. Esta situação deve, naturalmente, ser evitada.
Aqui está o exemplo mais simples: conseguir uma posição. Uma posição é ou ordens em aberto no MT4 ou posições em aberto no MT5.
Se você tiver acesso total, ao selecionar uma posição - o usuário tem que lembrar quais variáveis podem ser lidas agora, quais variáveis são atualmente inválidas, quais variáveis ele pode mudar, quais não são.
Com a interface, as coisas são muito mais simples. Você conseguiu, e só tem duas funções: obter o número de componentes, e obter um ponteiro para um componente constante. É ISTO. Com estas duas funções - você não pode acessar fisicamente nenhuma "variável extra".
O contrário é que é verdade. Os usuários muitas vezes precisam conhecer variáveis internas para testar a qualidade dos módulos, por exemplo, e este não é o caso. E maneiras inteligentes especiais são inventadas para obter este acesso posteriormente. Portanto, não há informações redundantes em princípio, e aqueles que não precisam delas podem simplesmente não utilizá-las.
Isto é exatamente o oposto. Os usuários freqüentemente precisam conhecer variáveis internas para testar módulos de qualidade, por exemplo, e este não é o caso. E eles inventam maneiras especiais e inteligentes de obter este acesso posteriormente. Portanto, não há informação desnecessária e aqueles que não precisam dela simplesmente não a utilizam.
Se você precisar de "acesso astuto para obtê-lo" - isso indica um projeto de sistema incorreto.
Por exemplo, se escrevemos um gerador de sinais de entrada - não devemos ter acesso a informações relativas, digamos, à gestão de dinheiro.
É claro que durante a depuração pode haver uma situação, digamos, quando não houve entrada - devemos eliminar imediatamente a situação, quando isso aconteceu porque a administração do dinheiro proibiu a operação (digamos, não há margem suficiente). E como você sabe sobre isso pelo gerador de entrada? Você não tem - você não tem acesso. Mas neste caso - basta certificar-se de que o gerador tenha definido um sinal para a entrada, e funcionou corretamente. Não houve nenhuma entrada - por alguma outra razão, que está fora do gerador de entrada. Descobrir a razão neste caso é realmente mais difícil do que se tivermos acesso direto a todas as variáveis da administração do dinheiro. Mas, é muito mais perigoso que em operações normais e rotineiras - nós, tendo acesso a elas - "entremos no lugar errado".
Se for necessário 'acesso complicado para obter', isso é uma indicação de projeto de sistema defeituoso.
O desenvolvimento é, antes de tudo, um processo natural da mente.
Neste processo, as idéias são formadas livre e até espontaneamente.
Seguir um OOP torna difícil transformar o código livremente.
No processo natural de desenvolvimento, o próprio código encolhe gradualmente e universaliza-se.
No processo natural, as funções não se separam, mas, ao contrário, crescem e se unem em grandes blocos.
Grandes blocos resolvem uma ampla gama de tarefas.
O OOP impede a formação desses blocos, deixando o código fragmentado.
O OOP cria acesso complicado, o que aumenta constantemente o número de referências a variáveis.
Os benefícios da granularidade são contrabalançados pela dificuldade de fazer um mecanismo coerente.
A principal desvantagem: O OOP nos força a seguir a maneira de dividir o código em uma série de funções.
É mais fácil para um humano aceitar um código fragmentado, mas a fragmentação é contra-indicada a qualquer mecanismo.