Programação OOP vs procedimento - página 38
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
MeuOnInit() parece mais ou menos o mesmo - uma dúzia de linhas...
Então?
Uau!
Eu estava me perguntando: existe alguma outra maneira na programação moderna para confundir o problema do nível de ovos de uma maneira mais fria?
Quanto ao fato de que este é todo o programa... não há mais nada lá :-)
É claro que não.
Tudo o resto em cinzas + R (ele não conta)
A depuração tem tudo a ver com depuração da lógica: a intersecção de duas mashas está lá, mas o sinal não está. Há problemas na compreensão dos valores das variáveis do terminal. O principal aqui é não mudar o tipo de conta e, de preferência, não mudar o corretor.
Eu não sei sobre todas essas paixões que eles escrevem aqui acima.
É claro que não.
Tudo o resto em cinzas + R (ele não conta)
A depuração tem tudo a ver com depuração da lógica: a intersecção de duas mashas está lá, mas o sinal não está. Há problemas na compreensão dos valores das variáveis do terminal. O principal aqui é não mudar o tipo de conta e, de preferência, não mudar o corretor.
Não estou ciente de nenhuma das paixões descritas acima.
Francamente - você tem um relato real? As paixões são apenas de encontros com o mundo real e as contusões de exploração/manutenção... e para um testador, não importa o que escrever e como escrever...
OOP é um método para separar, embrulhar e esconder partes de um mecanismo. Se isso é necessário ou não, cabe ao desenvolvedor decidir. Não tem nada a ver com o aumento da eficiência do mecanismo. Ele estrutura a maneira de pensar, sim. Não se sabe se ele estrutura corretamente ou não. Se é necessário depende da pessoa. imho.
Há sempre um problema quando se escrevem funções:
1. você escreve uma função
2. você escreve outra função e vê que ela é muito semelhante, mas diferente da primeira.
Há sempre um dilema: você deve colocá-lo em um ou manter dois? Você fica mais versátil, mas com código mais complicado. Você obtém um código simples, mas um monte de funções. É assim com este OOP.
Se você conseguir alocar um pequeno número de classes que sejam bem estruturadas e compreensíveis,
se você escrever um monte de Expert Advisors
se você os modifica com freqüência por algum motivo
ENTÃO
O OOP é útil.
Se não, então não há necessidade de preencher sua cabeça com informações, o que não tem nada a ver com comércio, e seria melhor gastar tempo com R.
Boa sorte a todos vocês!
Francamente - pelo menos um relato real... As paixões são apenas de colisões com o mundo real e os hematomas de operação/manutenção... e o testador não se importa com o que escrever ou como escrever...
Desde 2008, incluindo a PAMM.
Não há problemas com a manutenção.
Mas com a exploração...
O spread é aumentado até 20, depois a margem é multiplicada, depois o gap, depois a luz é desligada.... então minha esposa limpa o pó nos botões de toque... Já estou farto disso. É por isso que este ramo é como estar na China.
Há sempre um problema quando se escrevem funções:
1. você escreve uma função
2. você escreve outra função e vê que ela é muito semelhante, mas diferente da primeira.
Há sempre um dilema: você deve colocá-lo em um ou manter dois? Você fica mais versátil, mas com código mais complicado. Você obtém um código simples, mas um monte de funções. É assim com este OOP.
Se você conseguir alocar um pequeno número de classes que sejam bem estruturadas e claras,
se você escrever um monte de Expert Advisors
se você os modifica com freqüência por algum motivo
ENTÃO
O OOP é útil.
Eu pessoalmente me esforço pela universalidade nas soluções. Isto requer "unir" funções similares em um bloco sem aumentar o tamanho do código. Ele aumenta a eficiência do mecanismo e não há necessidade de sobrecarga e divisão. Basta usar um pouco o cérebro e é tudo).
Ou seja, existiam duas funções de 20 linhas cada uma. Ambos realizam ações similares ou resolvem tarefas similares. Meu objetivo é fazer uma função de não mais de 20 linhas de código que execute o trabalho de ambas as funções. É assim que aparecem os blocos.
PS.
Havia uma rubrica para pérolas.
Isto está nele.
Um manual de programa não é documentação.
Um manual é uma descrição da funcionalidade de um programa (o que o programa pode fazer). É necessário para o usuário.
A documentação é uma descrição da estrutura do programa (como o programa é construído). É necessário para o programador.
Não há conflito de termos.
...
Se você não tem isso, então não adianta entupir sua cabeça com informações que não têm nada a ver com comércio, e é melhor gastar seu tempo com R
Boa sorte a todos vocês!
Demonstre na comercialização a eficácia do R-- você já gastou tempo suficiente com isso. Participar de concursos - 1.setembro; 2.trimestral
https://www.mql5.com/ru/forum/212596
1. Quanto a rentabilidade de seus EAs aumentou com o uso dos OOPs?
2. Em que medida o MTBF de sua EA diminuiu?
2. Que chatice4 o MTBF de um programa de computador... clínica!