Sobretaxa para a OLP - página 2
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
Naturalmente, o belo OOP deve ser pago com recursos e muito tempo de depuração. O OOP só faz sentido como um invólucro de texto útil ou com uso mínimo na inicialização em tempo de execução... Na verdade, o OOP foi apenas uma coisa de marketing da Microsoft para aumentar os custos do horário de trabalho dos programadores e para estimular a compra de equipamentos mais avançados. E eles mesmos não são tolos e escrevem todo o software em C e assembler.
que monte de porcaria.
todos sabem que os programadores da MS escrevem diretamente em código de máquina
todo programador tem um livro com códigos de máquinas processadoras em sua mesa e eles apenas queimam os códigos em cartões perfurados
Bill Gates pode compilar um sistema operacional em sua cabeça).
Que monte de porcaria.
Todos sabem que os programadores da MS escrevem diretamente em código de máquina
Sua palhaçada não é muito clara, sabe-se que as inserções de linguagem de montagem são usadas para melhorar o desempenho do código...
Posso supor que o OOP é usado em terminal no mínimo ou nada, porque é difícil obter arquivos tão compactos sem grandes bibliotecas externas como em dotnet...
Você tem algum argumento significativo sobre a essência do que foi dito?
Verificar. Alexei está de fato apenas reagindo emocionalmente. E em essência, as objeções são as seguintes.
O OOP é muito útil quando você precisa suportar algum código complexo.
Certamente, não faz sentido aplicar todos os truques do OOP a um indicador-MA. Embora quando as aulas básicas são escritas - mesmo para MA - a abordagem OOP ainda é pelo menos tão boa quanto uma abordagem usual, processual.
A principal vantagem do OOP é revelada com o apoio de estruturas de objetos desenvolvidos. Quando o encapsulamento garante a ausência da necessidade de compreender todas as nuances das funções sobrecarregadas a cada vez. Quando é baseado no polimorfismo, areutilização do código torna-se muito mais elevada.
A essência do OOP está mais próxima do mundo real onde qualquer objeto está sempre relacionado a suas propriedades e tem certas regras de interação com o meio ambiente.
Sobre o "aumento do custo das horas de trabalho" - isto não é verdade. Certamente, ao projetar um sistema no estilo OOP, ele requer um pouco mais de trabalho do que na abordagem orientada para procedimentos. Entretanto, esses custos extras são mais do que compensados pela conveniência de manter e modificar o código escrito.
Pessoalmente, escrevo indicadores "Knee-Written" muito pequenos, sem nenhum objeto. Entretanto, quando é necessário algo mais (pelo menos em plataformas cruzadas) - eu sempre uso o estilo OOP e práticas existentes em bibliotecas de objetos.
Sua palhaçada não é muito clara, sabemos que inserções de linguagem de montagem são usadas para melhorar o desempenho do código...
Posso assumir que o terminal usa o mínimo ou nenhum OOP, porque sem grandes bibliotecas externas como em dotnet é difícil obter arquivos tão compactos...
1. OOP - ajuda muito quando você precisa suportar algum tipo de código complexo.
2. é claro, não faz sentido aplicar todos os truques do OOP para o indicador-MA. Embora, quando as aulas básicas são escritas - mesmo para MA - a abordagem OOP ainda é pelo menos tão boa quanto uma abordagem usual, processual.
3. A principal vantagem do OOP é revelada com o apoio de estruturas de objetos desenvolvidos.
1. Por exemplo... Slogans cativantes são bons, mas não está claro o que significam exatamente...
2. Já foi dito que como um invólucro de texto OOP é bom, mas isso é porque não foi atualizado na programação de procedimentos.
3) Por que precisamos multiplicar essas "estruturas desenvolvidas"? Será destrutivo para o desempenho do código e não é certo que será mais fácil e rápido pegar bugs nele.
Os compiladores modernos otimizam muitas vezes melhor que um programador médio ou mesmo bom programador.
Talvez algumas coisas simples e triviais possam, mas apenas porque as pessoas se sentaram e escreveram manualmente o algoritmo, mas se algo não padrão, está longe de ser certo, especialmente se as características OOPesheh forem encontradas lá.
Nos motoristas, sim, eles usam o assebler, mas não por causa da velocidade, é mais fácil trabalhar com o hardware..,
Bem, as pessoas não são estúpidas - por que querem algo complicado e confuso que também é lento?
E por exemplo? Slogans atraentes são legais, mas é difícil entender exatamente do que estamos falando... 3.
2. Já foi dito que como um invólucro de texto OOP é bom, mas isso é porque não foi atualizado na programação de procedimentos.
3) Por que devemos multiplicar estas "estruturas desenvolvidas"? Seria terrível para o desempenho do código e não é o fato de que será mais fácil e mais rápido pegar os bugs nele.
1. Por exemplo, você precisa de um conjunto de objetos. Isto poderia muito bem ser feito de forma processual ou baseado no CArrayObj e CObjest. Os problemas começarão quando você precisar mudar o comportamento de, digamos, adicionar ou apagar objetos ou classificá-los. No OOP, o suporte para uma matriz de ponteiro propriamente dita e o trabalho com ela é incluído nos objetos de base. A modificação de objetos descendentes que estão de fato contidos na matriz não afeta nada. Em estilo processual - modificando objetos reais que estão realmente contidos em uma matriz - geralmente afeta muito mais lugares, pelo menos porque temos que considerar mudanças no tamanho dos objetos. O que levará mais facilmente a erros.
Cross-platform - também muito mais conveniente de organizar em estilo OOP. Quando a pedido, digamos, uma posição comercial - obtemos uma interface, e não importa em que plataforma trabalhamos - a interface oferece funções virtuais, nas quais podemos obter todos os dados de todos os pedidos (para MT4) ou posições (MT5), e, do ponto de vista dos especialistas - não há diferença. O Expert Advisor não precisa saber em que plataforma ele trabalha.
2. Bem, "acabamento na programação de procedimentos" significa "escrever objetos-procedimentos", ou seja, criação de algumas ligações entre dados e procedimentos, que representam objetos no OOP.
E então temos, digamos, vários tipos de pedidos, que têm muito em comum. Seria razoável fazer um objeto COrderInfo - que seria o objeto base, e seus descendentes representariam diferentes tipos de ordens. Neste caso, o processador comercial (tenho a classe CTradeProcessor) suportará automaticamente exatamente aquela ordem, que lhe foi passada, pelos procedimentos que são necessários para processar esta ordem.
É mais fácil pegar os bugs onde há menos ligações cruzadas. O que é exatamente fornecido pelo encapsulamento e pelo polimorfismo. Solicitamos que a interface de posição comercial (CTradePositionI) e todas as conexões com classes reais que representam esta posição (CMT4PositionInfo,CMT5PositionInfo) sejam realizadas somente através desta interface, e isto contribui precisamente para uma correção de erros mais fácil do que se trabalharmos diretamente com funções reais que retornem dados de posição comercial.