Mt4 Fim do apoio. - página 11
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
Vladimir:
Talvez para organizar a interface com o usuário? É aqui que muitas variações no OOP são criadas, uma biblioteca de componentes visuais em Delphi. Assim, os Expert Advisors e scripts são projetados para substituir os humanos no computador, esta interface contradiz diretamente seu propósito, não é necessária. Ou seja, isso está no caminho. Assim como os itens desnecessários em um canivete. Ou um pregador na ponta do cabo de aço de um martelo universal - não apenas arranha, mas também desloca o centro de gravidade do atacante para o cabo.
Discordo de você sobre este ponto em particular.
Uma interface gráfica pode ser necessária para algotraders que entendem que uma EA totalmente automatizada é, de longe, muito menos eficaz do que uma EA semi-automatizada. A combinação de comércio automatizado e manual pode ser mais profissional e lucrativa do ponto de vista comercial. Quando as pessoas perceberem isso, seus robôs definitivamente precisarão de uma interface.
1. O graph_id pode ser lido por uma pessoa que fala russo mais rapidamente do que o m_chart_id.
2. Se houver centenas de variáveis em um programa, o idioma russo oferece suporte indispensável.
Tudo isso pode ser testado em uma experiência.
A velocidade de leitura e compreensão do código no idioma nativo será sempre mais rápida e a memorização será melhor.
Você só precisa elaborar as regras de nomeação de variáveis em russo. Em vez de "variável_para_posição_geral_de_armazém_geral, apenas: lucro_geral".
Se houver centenas de variáveis em um programa, a maioria delas provavelmente pode ser combinada por estruturas. Além disso, não se esqueça de utilizar funções.
Muitas variáveis não têm nenhum sentido, porque são contadores, armazenamentos temporários de dados intermediários, e são usadas atrás de um monte de parênteses. E o melhor de tudo, atrás de todos os parênteses podemos usar novamente as mesmas variáveis, mas novamente entre parênteses {....}
Ou escreva inicialmente no OOP.
Parece-me que a essência de sua rejeição do OOP está nisto. Eu poderia estar errado, é claro, mas normalmente sinto as pessoas.
Na minha opinião, o problema com a maioria dos não-OBOs é uma resistência interna à "limitação dos direitos legais".
Um programador da velha escola está acostumado a ter acesso total a qualquer dado, qualquer bloco, qualquer entidade de programa a qualquer momento. E a abordagem OOP implica o oposto - a limitação máxima dos direitos, quando você - tem acesso a uma parte muito pequena dos dados e ações do programa.
Se bem me lembro, eu não gostei muito. Nos primeiros tempos do Windows, eu me lembro de estar muito enojado pelo acesso à memória protegida - não consigo acessar o endereço que gosto, então e se ele estiver no núcleo do sistema? Gostaria que fosse lido a partir de um programa ou que fosse alterado de qualquer forma! Eu até programei um controlador de acesso direto à memória, que enviaria dados para a "área permitida" da "área proibida", contornando as restrições do sistema.
Mas, com o tempo, eu realmente apreciei todas essas restrições. O acesso "desnecessário" pode sempre se transformar em erros. Portanto, é muito sensato transferir o trabalho de controle de acesso - para o compilador.Restringir o acesso aqui se revela "infalível", e não "violação de seus direitos". Se você precisa de um acesso que não tem, isso só significa que você projetou o sistema errado - você deveria tê-lo providenciado se precisasse dele.
E agora - pelo contrário, eu sempre limito o acesso tanto quanto possível. A qualquer momento, deve haver acesso somente às entidades que sejam necessárias. Todas as outras entidades devem ser inacessíveis. Isto o protege de erros no acesso a lugares que você não deveria, e também o acostuma a uma certa seqüência de desenvolvimento do sistema, onde cada operação é realizada em um lugar, e nenhum outro lugar é afetado.
Por exemplo, eu odeio os ludes na forma de bibliotecas, só porque eu não sei o que elas colocam lá e como isso pode me ajudar, é mais fácil escrever mais uma dúzia de funções
semelhante ao que estou acostumado com a Re-Tag Konow.
E por quê?
Uma e a mesma função é necessária em muitos lugares - por que copiar funções quando você pode ter tudo nas bibliotecas, e não desordenar o código principal com bloqueios desnecessários?
E por quê?
Uma e a mesma função é necessária em muitos lugares - por que copiar funções quando você pode ter tudo em bibliotecas, e não desorganizar o código principal com blocos desnecessários?
Você é bom em encontrar argumentos, Nikolai).
A avó também pode assimilar tudo sem nenhum problema. Ela apenas subconscientemente não quer que nenhuma bugiganga arraste sua mente acomodada para um ciclo de informações desnecessárias. Corretamente).
Peter, então acontece que você é uma avó.
Olá
Talvez eu possa obter alguma ajuda aqui. Tenho uma pergunta para os desenvolvedores do MT4. Onde pode ser expressado. Se neste fórum, então em qual tópico? Ou em outro lugar? Se você sabe, por favor, me diga.
Discordo de você sobre este ponto em particular.
Uma interface gráfica pode ser necessária para algotraders que percebem que uma EA totalmente automatizada é, de longe, muito menos eficaz do que uma EA semi-automatizada. A combinação de comércio automatizado e manual pode ser mais profissional e lucrativa do ponto de vista comercial. Quando as pessoas perceberem isso, seus robôs definitivamente precisarão de uma interface.
Você apóia totalmente a pessoa que diz que o mql só deve ter funções de acesso ao servidor, e tudo mais através de muletas deve ser programado por ferramentas de desenvolvimento de terceiros. Não se desvie da linha do partido. Seja consistente - despeje todos os seus desenvolvimentos no mql e faça uma ponte - em estúdio, por exemplo - ou onde quer que você vá escrever suas telas... Em seguida, informe sobre sua próxima vitória sobre a usina.
Por exemplo, eu odeio os ludes na forma de bibliotecas, só porque eu não sei o que elas colocam lá e como isso pode me ajudar, é mais fácil escrever mais uma dúzia de funções
semelhante ao da Retrog Konow.
Bem, a lei da conservação de energia: por que descompilar a biblioteca e compreendê-la se tudo funciona sem ela?
P.S.
Você já viu meu top sobre alce?
Quando seus códigos começam a transbordar 10, 20, 30, ... A partir de então, a partir de 100 mil linhas, volte e me diga como você copia seus códigos em tal volume.
Na minha opinião, o problema com a maioria dos não-OBOs é uma resistência interna à "limitação dos direitos legais".
Um programador da velha escola está acostumado a ter acesso total a qualquer dado, qualquer bloco, qualquer entidade de programa a qualquer momento. E a abordagem OOP implica o oposto - a limitação máxima dos direitos, quando você - tem acesso a uma parte muito pequena dos dados e ações do programa.
Se bem me lembro, eu não gostei muito. Nos primeiros tempos do Windows, eu me lembro de estar muito enojado pelo acesso à memória protegida - não consigo acessar o endereço que gosto, então e se ele estiver no núcleo do sistema? Eu poderia até mesmo querer lê-lo de um programa ou mudá-lo de qualquer forma! Até programei um controlador de acesso direto à memória, que enviaria dados para a "área permitida" a partir da "área proibida", contornando as restrições do sistema.
Mas, com o tempo, eu realmente apreciei todas essas restrições. O acesso "desnecessário" pode sempre se transformar em erros. Portanto, é muito sensato transferir o trabalho de controle de acesso - para o compilador.Restringir o acesso aqui se revela "infalível", e não "violação de seus direitos". Se você precisa de um acesso que não tem, isso só significa que você projetou o sistema errado - você deveria tê-lo providenciado se precisasse dele.
E agora - pelo contrário, eu sempre limito o acesso tanto quanto possível. A qualquer momento, somente as entidades que precisam ser acessadas devem estar disponíveis. Todos os outros objetos devem ser inacessíveis. Isto o protege de erros no acesso a lugares que você não deveria, e também o acostuma a uma certa seqüência de desenvolvimento do sistema, onde cada operação é realizada em um lugar, e nenhum outro lugar é afetado.
Você deu um bom exemplo do que o OOP pode repelir.
No meu caso, foi um pouco diferente. Comecei a aprender o OOP, mas em uma certa etapa deixei de ver qualquer benefício prático em usá-lo. Até hoje, isso não mudou. Tudo porque eu formei minha abordagem, o que empurrou o OOP para fora de minha prática.
Esta afirmação - que a limitação de acesso é uma proteção necessária que poupa de erros - é algo que eu não consigo entender de forma alguma. Se os nomes das variáveis coincidirem em diferentes partes do programa, é claro que sim. Mas se houver uma memória global comum de todas as principais variáveis globais em uma matriz, você não precisará de restrições e não haverá confusão.