Sobretaxa para a OLP - página 3
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
1. Por exemplo, você precisa de um conjunto de objetos.
Os problemas começam quando você precisa mudar o comportamento de, digamos, adicionar ou remover 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 muito mais facilmente levará a erros.
2. 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 é possível obter todos os dados sobre 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/ela trabalha.
3. bem, "terminar na programação de procedimentos" é "escrever objetos-procedimentos", ou seja, a 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 herdeiros representariam diferentes tipos de ordens. Nesse caso, o processador comercial (eu tenho a classe CTradeProcessor) suportará automaticamente exatamente essa ordem, que lhe foi passada, pelos procedimentos necessários para o processamento dessa ordem.
5.É mais fácil pegar bugs onde há a menor quantidade de ligações cruzadas. Isto é assegurado pelo encapsulamento e pelo polimorfismo. Solicitamos a interface de posição comercial (CTradePositionI) e todas as conexões com classes reais, representando esta posição (CMT4PositionInfo,CMT5PositionInfo) são feitas somente através desta interface, o que apenas contribui para uma mais fácil correção de erros, do que se trabalharmos diretamente com funções reais que retornem dados de posição comercial.
1. Para quê?
Por que a mesma função não pode ser compilada em plataformas diferentes?
3. a idéia era embalar o texto das funções pelo tipo de estrutura para tornar mais conveniente a referência a elas por analogia com a referência a uma função como um membro de classe. Em princípio, nenhum objeto precisa ser criado para este fim.
4. Seria mais razoável fazer uma única função com suas configurações, ao invés de multiplicar vários objetos e conexões desnecessárias através de interfaces.
5. Além disso, todos esses links devem ser programados e depois rastreados através das interfaces e afins, onde os bugs podem ser difíceis de serem capturados. Esta ocupação é desnecessária e sem sentido desde o início.
1. Por exemplo, para quê?
2) Por que a mesma função não pode ser compilada em plataformas diferentes, para que você não tenha que criar interfaces para ela?
Eu me referia à embalagem do texto das funções pelo tipo de estrutura para um acesso mais conveniente, semelhante a abordar uma função como um membro da classe. Em princípio, nenhum objeto deve ser criado para este fim.
4. É mais inteligente fazer uma única função com configurações ao invés de multiplicar vários objetos e conexões desnecessárias através de interfaces.
5. Além disso, todos esses links devem ser programados e depois rastreados através das interfaces e afins, onde os bugs podem ser difíceis de serem capturados. Esta ocupação é desnecessária e sem sentido desde o início.
1. Bem, a classe CTradePosition é essencialmente uma lista de pedidos em aberto. E para eles, seria muito útil ter uma interface, uma classe base, e classes reais.
2. Há apenas uma interface. Para todas as plataformas. E no caso do OOP, nós não pensamos realmente onde estamos trabalhando. Não temos que considerar coisas dependentes da plataforma e dependentes da ordem.
E qual é a diferença entre objeto e função nesta embalagem? É o que eu estou dizendo - é essencialmente a mesma coisa. No caso de um objeto - uma função de construtor automático também é adicionada, no entanto, por padrão - ele está vazio.
4. Exatamente, esta mesma "função única com ajustes" é a fonte dos problemas. Porque geralmente há muitas configurações. E eles não estão dispersos em diferentes níveis de hierarquia de classes, mas concentrados nesta mesma função. Mas a interface permite deixar todas as configurações não utilizadas em um determinado contexto "fora de consideração" - o que tem um efeito muito bom na compreensão do código e possibilidades de erros e sua detecção. Esta é exatamente a principal vantagem do OOP - toda a funcionalidade está "dispersa" em objetos em diferentes níveis hierárquicos e quando se trabalha com esta ou aquela parte dela - outras não interferem. Em uma única função com ajustes, por outro lado, toda a funcionalidade está sempre disponível, mesmo que seja supérflua. A principal desvantagem é que é muito mais difícil detectar erros em uma função tão simples.
5. Em qualquer caso, estes links são necessários e devem ser programados - são, de fato, os mesmos ajustes em uma única função. Por exemplo, no meu exemplo - em uma única função temos acesso à diferença de plataformas, diferentes tipos de ordem, diferença na representação de posição - tudo isso deve ser levado em conta. E quando há uma interface - tudo é "cortado" - somente o que está definido na interface pode ser levado em conta.
Esse é o ponto de encapsulamento, para limitar o acesso de um bloco de código a outro bloco. Pelo contrário, você sugere ter "uma grande função universal com configurações máximas", para que qualquer pessoa que tenha acesso a esta função tenha o máximo de possibilidades. Pelo contrário, o caminho certo é, pelo contrário, limitar ao máximo o usuário, se um bloco do programa precisa da funcionalidade de outro bloco - ele deve ter apenas esta funcionalidade, e não um pouco mais. Esta é a chave para um código mais estável e livre de erros.
1. Bem, a classe CTradePosition é essencialmente uma lista de pedidos em aberto. Os pedidos podem ser diferentes, e para eles é muito conveniente ter uma interface, uma classe base, e classes reais.
E o que há de errado em manter as ordens em uma série de estruturas, ou na forma como elas são implementadas no MT4?
O que há de errado em manter as ordens em uma série de estruturas ou como implementadas no MT4?
Porque cada usuário tem demasiados direitos e demasiadas informações desnecessárias ao acessar esta matriz.
A coisa certa a fazer, em minha opinião, é dar ao usuário apenas a parte da funcionalidade de que ele precisa - apenas usando uma interface pré-acordada para acessar os pedidos.
Que cada usuário tem demasiados direitos e demasiadas informações desnecessárias ao acessar esta matriz.
A coisa certa a fazer, em minha opinião, é dar ao usuário apenas a parte da funcionalidade que ele precisa - apenas usando uma interface pré-acordada para acessar os pedidos.
Você pode criar seu próprio tipo de dados para pedidos, não há necessidade de nenhuma interface, objetos e outros artifícios desnecessários, que criam bugs e instabilidades desnecessários.
Você pode criar seu próprio tipo de dados para pedidos, não há necessidade de nenhuma interface, objetos e outros artifícios desnecessários, que criam bugs e instabilidades desnecessários.
Minha experiência mostra que você precisa fazê-lo.
Fui por aqui há cerca de cinco anos, na época, no MT4. (Não porque eu não soubesse do OOP, mas porque eu era preguiçoso demais para me preocupar com interfaces e herança, especialmente porque naquela época o MT4 e o MT5 eram significativamente diferentes em termos de implementação do MQL). Isto me levou à compreensão de sua falácia. Isto não é "sabedoria", mas uma limitação razoável, uma espécie de "infalível". Se você sempre se lembra do que cada uma de centenas de variáveis é responsável - você não precisa de encapsulamento. Não me lembro disto, e prefiro ter o menor número possível de entidades disponíveis em cada bloco de um programa.
Assim que o MT4 apareceu OOP - Comecei imediatamente a traduzir todos os meus desenvolvimentos em uma única forma, baseada em interfaces.
1. Minha prática mostra que, de fato, é necessário. Isto me levou a entender sua falácia.
2. Não me lembro disso, e prefiro ter o menor número possível de entidades acessíveis em cada bloco de software.
1. Nunca se explica para que serve e para que é a falácia. Como este é um tipo especial de dado, você pode configurar o acesso como desejar. O exemplo é claramente uma escolha infeliz.
2. É obviamente errado pensar em negar ao programador o acesso a seus dados em seu programa sob o pretexto de que ele cometerá um erro ali, já que terá de criar todo tipo de soluções complicadas para permitir o acesso do programador e criar um código instável com muitos erros possíveis no caminho. É como proibir o motorista de tocar o volante e, em seguida, inventar soluções de trabalho - interage como ele pode então dirigir o carro em vez de dirigir o volante.
2. Proibir o acesso de um programador aos seus dados em seu programa sob o pretexto de que ele alegadamente faria asneira - é obviamente um pensamento equivocado, porque então você tem que criar todo tipo de soluções sofisticadas para dar ao programador acesso e ao longo do caminho o código instável é criado com um monte de possíveis bugs. É como proibir o motorista de tocar o volante e, em seguida, inventar soluções de trabalho - interage como ele pode então dirigir o carro em vez de dirigir o volante.
Não. Em qualquer lugar do código - somente o que é necessário naquele lugar deve estar disponível - todo o resto deve ser cortado, se possível.
Em sua situação com o motorista - significa que é razoável proibir o motorista de tocar o volante enquanto o carro estiver estacionado. Assim, ele não tenta girar uma roda enquanto o carro está estacionado - na verdade, naquele momento, os sensores de alinhamento das rodas, por exemplo, podem ser conectados às rodas, e agarrar a roda pelo motorista levará a erros na definição desses ângulos.
A idéia é que, a qualquer momento, somente a funcionalidade que o programa precisa naquele momento está disponível e tudo o mais estaria fechado. Há muito tempo estou convencido de que esta é a maneira de cometer o menor número possível de erros.
Não. Em qualquer lugar do código - somente o que é necessário naquele lugar deve estar disponível - todo o resto deve ser aparado, se possível.
A idéia é que a cada momento somente aquelas funções estão disponíveis para o programa que são necessárias naquele momento e todo o resto deve estar bloqueado. Aprendi há muito tempo que esta é a maneira de cometer o menor número possível de erros.O incômodo constante com o que proibir e o que permitir é obviamente uma exigência muito ilógica, a menos, é claro, que o programador esteja bêbado ao escrever código e não se controle que ele possa escrever um monte de código que ele não entende. Penso que não ajudará um programador alcoólatra a evitar erros de código, e pessoas sóbrias não precisam disso em primeiro lugar.
A preocupação constante com o que proibir e o que permitir é obviamente uma exigência muito ilógica, a menos, é claro, que o programador se sente para escrever código enquanto está bêbado e não tem controle sobre si mesmo que pode escrever um monte de código que não entende. Penso que não ajudará um programador alcoólatra a evitar erros de código, e pessoas sóbrias não precisam disso em primeiro lugar.
Este é um requisito muito lógico ao qual muitas pessoas se dirigem.
Você não precisa - bem... não utilize o OOP.