Programação OOP vs procedimento - página 4
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
George Merts:
Erm... Eu não entendi bem o ponto.
O objetivo era separar o TC do terminal. O código deve ser compilado em ambas as plataformas sem nenhuma alteração. A super tarefa - transferir todo o TS escrito para a WealhtLab Developer escrevendo apenas classes de trabalho com o servidor comercial.
//--------------------------------------------------
Perguntei sobre a tarefa atual a fim de comparar suas soluções por vários critérios e chegar a uma conclusão sobre a eficácia de cada um deles. Você está tirando a conversa da parte prática. Ao afirmar a eficácia do OOP, você deve ser capaz de prová-la na prática. Mas eu estou pronto para tentar provar minha opinião.
Então, qual é o problema atual? Espero que você se lembre disso)
Se você usa apontadores para funções, você pode prescindir do OOP. Mas se você não usar apontadores, você deve entender que não pode alcançar o OOP.
Presumo que você não seja um programador? Então lembre-se onde você estava 2017.07.05 14:55 GMT 00, com quem você estava falando e sobre o que ))
Se você usa apontadores para funções, você pode prescindir do OOP. Mas se você não usar apontadores, você deve entender que não pode alcançar o OOP.
Não. Até que não haja nenhuma tarefa concreta que me mostre que não posso alcançar o OOP, não posso agarrá-lo. Infelizmente. Estas são apenas palavras.
Atualmente, tenho 4 anos de prática de programação. Você pode multiplicá-los com segurança por 2, porque estou programando muitas horas todos os dias. Durante este tempo, eu resolvi inúmeras tarefas diferentes. Eu ainda não usei o OOP. Não consigo entender por que preciso dele. Em minha prática, todas as tarefas são resolvidas sem ele não menos, e às vezes até mais eficientemente.
Não. Até que não haja nenhuma tarefa concreta que me mostre que não posso alcançar o OOP, não posso de forma alguma alcançá-lo. Infelizmente. Estas são apenas palavras.
Imagine um programa hipotético que muda seu algoritmo dependendo de parâmetros externos, poderia haver um grande número de variantes. Podemos resolvê-lo sem OOP, mas como pareceriam estúpidos aqueles interruptores de vários andares. Além disso, é claro que o desempenho irá diminuir à medida que o número de variantes aumentar. Também é claro que a construção durante a inicialização ocorre no OOP e depois não ocorre nenhuma ramificação desnecessária no processo de trabalho, ou seja, o aumento do número de variantes não diminuirá o desempenho.
Uma característica distintiva da programação estruturada é a divisão dos programas em blocos de código,
que realizam uma tarefa específica. Neste caso, os blocos de construção são funções
e módulos (que podem ser movidos para arquivos separados).
Mais moderna é a programação orientada a objetos (OOP).
O conceito de OOP se refere mais à organização de dados. O OOP facilita a vida de um programador.
Os conceitos-chave no OOP são objetos e classes.
As classes são estruturas nas quais as funções são adicionadas. E os objetos são variáveis estruturadas ou instâncias de classes
A programação estruturada é o primeiro passo. Tendo dominado isso, o programador obtém uma vantagem. O OOP é o próximo passo com a seguinte vantagem
Vamos resolver um problema em particular e comparar.
Aqui está uma tarefa simples (seria necessário escrever muito para explicar em detalhes).
Tudo acontece na OnTick(). Suponha, verificamos algumas condições e abrimos um pedido. A condição não importa, vamos supor, é alguma máxima ou mínima.
O robô fica naturalmente em algum gráfico e recebe citações deste símbolo. É claro que temos não apenas uma função OnTick, mas também outras funções: OnTrade, OnTimer, funções personalizadas, etc.
Portanto, todas as variáveis que são compartilhadas devem ser declaradas fora destas funções no início do código. Por exemplo, como o nome do símbolo, perguntar, licitar, distribuir, o número de dígitos da cotação, etc. Haverá dúzias delas.
Este robô comercializará em apenas um símbolo, ou seja, onde ele se encontra. Suponhamos que existam 20 gráficos deste tipo e instalaremos o mesmo robô em todos eles para comercializar simultaneamente para todos os 20 pares.
Mas este não é um robô comercial de múltiplas moedas, como alguns comerciantes no mercado têm apontado.
Aqui precisamos transformá-lo em um robô com várias moedas. Ou seja, colocamos em qualquer gráfico (apenas em 1 gráfico) e ele abre negócios para 20 pares. Isso significa que o lançamos no modo de teste em modo solitário e ele será comercializado nos pares que estão no Market Watch.
Veja como você vai implementá-lo sem o OOP. Você irá transformar todas as variáveis comuns em conjuntos de 20 elementos?
E quanto às funções que serão chamadas simultaneamente para todos os pares?
Você não pode passar sem o OOP. :)
P.S. Quero notar que não tenho educação russa, e consequentemente escrevi durante muito tempo, e não tive tempo de ler várias páginas.
Se você usa apontadores para funções, você pode prescindir do OOP. Se você não usar apontadores, você mesmo deve perceber que não pode alcançar o OOP.
Eu discordo. Eu costumava escrever programas de TV digital em uma época, o compilador era C++, mas era usado dentro de C porque a memória era escassa. Os ponteiros para as funções foram utilizados muito extensivamente, mas isto não está nem perto do OOP.
...
Veja como você vai fazer isso sem o OOP.
...
A questão que é mais relevante aqui não é "como", mas "por quê"? Por que você precisaria codificar algo que já está implementado no terminal - você só precisa abrir o número necessário de gráficos e anexá-los à EA. Além disso, para símbolos e cronogramas diferentes, os parâmetros provavelmente serão diferentes.
Eu discordo. Eu costumava escrever programas para TV digital, o compilador era C++, mas era usado em C porque a memória era escassa. Os ponteiros para as funções foram utilizados muito extensivamente, mas não está nem perto do OOP.
Não é muito conveniente, mas você pode fazer com indicações somente no que diz respeito ao desempenho.
E a conveniência é um conceito relativo.
Imagine um programa hipotético que muda seu algoritmo dependendo de parâmetros externos, poderia haver um grande número de variantes. É possível resolvê-lo sem OOP, mas como pareceriam estúpidos aqueles interruptores de vários andares. Além disso, é claro que o desempenho irá diminuir à medida que o número de variantes aumentar. Também está claro que com o OOP há uma construção na inicialização e então nenhuma ramificação desnecessária durante o trabalho; ou seja, um número crescente de variantes não diminuirá o desempenho.