Recorde no mercado - página 31

 
Vladislav Andruschenko:

Provavelmente porque eu não trabalho para uma empresa. E eu acho mais fácil usar a programação de procedimentos do que o OOP.

Tem havido muito debate sobre isso, é claro.

Bem, ainda na última semana eu tenho feito algumas modificações no algoritmo de estimativa da qualidade comercial para minha Liga TS. E estou muito feliz que tudo seja baseado em interfaces virtuais.

A questão é que antes do saque máximo foi estimado apenas pelo balanço. E eu queria fazer uma estimativa por Equidade. Mas para fazer isso, ao analisar o histórico - para cada transação é necessário solicitar as séries cronológicas, e ver qual foi o máximo de saque da transação, com base nos preços de então.

Agora lembre-se, que meu código é portátil, significa que baseado na mesma interface - tanto o MT4 como o MT5 funcionam. Assim, para cada plataforma - chama a classe apropriada com suas próprias funções, que são visivelmente diferentes. Assim, enquanto eu estava modificando o código - provavelmente uma dúzia de vezes eu estava em uma situação, quando não conseguia acessar diretamente os dados necessários - as interfaces não o permitiam. E cada vez que eu me certificava de que estava correto, que as interfaces tinham me restringido - se eu tivesse "acessado" esses dados diretamente - isso teria levado a erros em outras partes do programa. Os dados que eu precisava, eu tinha que acessar de uma maneira diferente, através de consultas adicionais, o que me permitia ter certeza de que nenhuma outra parte fosse afetada.

Em resumo: mais uma vez estou convencido de que o princípio "em cada lugar o usuário deve ter acesso somente àquelas estruturas que ele precisa no momento e nenhuma outra" é absolutamente correto. Você não pode permitir que o usuário tenha sempre acesso a tudo - está repleto de erros de modificação.

Mas por outro lado - pessoas que estão acostumadas a um estilo processual - simplesmente se limitam em tais casos, lembrando quais dados podem ser alterados a partir de um determinado local e quais não podem.

 
Georgiy Merts:

Bem, ainda na última semana eu tenho feito algumas modificações no algoritmo de avaliação da qualidade comercial para minha Liga TS. E estou muito feliz que tudo seja baseado em interfaces virtuais.

A questão é que antes do saque máximo foi estimado apenas pelo balanço. E eu queria fazer uma estimativa por Equidade. Mas para fazer isso, ao analisar o histórico - para cada transação é necessário solicitar as séries cronológicas, e ver qual foi o máximo de saque da transação, com base nos preços de então.

Agora lembre-se, que meu código é portátil, significa que baseado na mesma interface - tanto o MT4 como o MT5 funcionam. Assim, para cada plataforma - chama a classe apropriada com suas próprias funções, que são visivelmente diferentes. Assim, enquanto eu estava modificando o código - provavelmente uma dúzia de vezes eu estava em uma situação, quando não conseguia acessar diretamente os dados necessários - as interfaces não o permitiam. E cada vez que eu me certificava de que estava correto, que as interfaces tinham me limitado - se eu tivesse "acessado" esses dados diretamente - isso teria levado a erros em outras partes do programa. Os dados que eu precisava, eu tinha que acessar de uma maneira diferente, através de consultas adicionais, o que me permitia ter certeza de que nenhuma outra parte fosse afetada.

Resumindo: eu estava mais uma vez convencido de que o princípio "em cada lugar o usuário deve ter acesso somente àquelas estruturas que ele precisa no momento e nenhuma outra" era absolutamente correto. Você não deve deixar o usuário sempre ter acesso a tudo o que ele precisa - isso pode causar erros de modificação.

Mas, por outro lado - as pessoas acostumadas ao estilo processual - limitam-se em tais casos apenas lembrando quais dados podem e não podem ser alterados a partir do local determinado.

Sim, eu também tenho minhas próprias bibliotecas que trabalham igualmente no mt5 e mt4. Eu só escrevo 1 código, a biblioteca faz o resto.
E o código não é tão grande para transformar tudo em um OOP.
A propósito, por falar em levantamento de capital, eu usei exatamente isso em meu indicador.
Mas há muitas nuances aí. Em particular, não podemos obter o histórico de carrapatos de uma determinada barra. Portanto, os dados são aproximados.
 
Реter Konow:

Bem, essa é a concorrência. Não há nada que você possa fazer a respeito. Não desista. Continue avançando e ganhe. Caso contrário, você será deixado para trás.

Esqueça a OLP. Se esta pergunta o incomoda, posso lhe dizer que na programação você deve usar apenas o que você pode fazer sem. Se você pode fazer com estilo de procedimento - faça isso.

Meu princípio:"Se você pode prescindir de algo na solução de uma tarefa, definitivamente deve prescindir dela".

O cão precisa de uma quinta perna? :)

Exatamente.

Esse é o tipo de competição que você precisa.

 
Vladislav Andruschenko:

Você ficaria surpreso, mas eu ainda sofro com a programação de procedimentos.

Entrei em Pascal quando eu tinha 14 anos e não posso me mudar. E eu "aprendi as aulas" há muito tempo, mas não posso mudar de idéia...

Provavelmente porque eu não trabalho para uma empresa. E eu acho mais fácil usar a programação de procedimentos do que o OOP.

Os princípios do OOP não diferem muito da programação processual, tanto mais nos programas MQL as tarefas são altamente especializadas e muitas vezes não faz sentido desenvolver a estrutura interna de uma classe. Mais de 90% dos exemplos que utilizam classes no Codobase não são mais do que programação processual "envolvida em classe", porque as tarefas que são resolvidas por uma classe são realizadas apenas uma vez e a herança e o polimorfismo não são utilizados (porque não há necessidade).

E problemas graves, onde não há como não ter OOP - é um gráfico. Este problema já foi resolvido e está no acesso livre e você só precisa saber como usá-lo ou modificá-lo (como herança).

Eles já o fizeram e está disponível gratuitamente, é apenas uma questão de saber como utilizá-lo (gráficos em MQL) ou como modificá-lo (para usar herança).

ZZZY: isso é o que não vou dizer sobre a usabilidade em termos de ALGLIB - certamente deve ser "embrulhado" em uma classe normal!

 

Igor Makanu:

...

E tarefas sérias onde não se pode passar sem o OOP são gráficos.

Muito controverso)).

 
Реter Konow:

Muito controverso)).

Igor Makanu:

Os princípios do OOP não diferem muito da programação processual, especialmente nos programas MQL, as tarefas são altamente especializadas e muitas vezes não faz sentido desenvolver a estrutura interna de uma classe. Mais de 90% dos exemplos que utilizam classes no Codobase não são mais do que programação processual "envolvida em classe", porque as tarefas que são resolvidas por uma classe são realizadas apenas uma vez e a herança e o polimorfismo não são utilizados (porque não há necessidade).

E problemas graves, onde não há como não ter OOP - é um gráfico. Este problema já foi resolvido e está no acesso livre e você só precisa saber como usá-lo ou modificá-lo (como herança).

Eles já o fizeram e está disponível gratuitamente, é apenas uma questão de saber como utilizá-lo (gráficos em MQL) ou como herdá-lo (como utilizar a herança).

ZZZY: isso é o que não vou dizer sobre a usabilidade em termos de ALGLIB - certamente deve ser "embrulhado" em uma classe normal!


Depende para quê.

Para facilidade de uso por outros usuários?

Possivelmente, sim.

Para que os usuários não tenham vontade de "brincar" e causar qualquer dano.


Eu uso 5 funções de desenho para meus gráficos (texto, botão, caixa de seleção, campo, fundo) !)

Tudo está claro para mim. Outros não precisam vê-lo.

 
Vladislav Andruschenko:

Exatamente.

Esse é o tipo de competição de que precisamos.

Eu sonho que tal concorrência cresça em nosso mercado. Somente o Mercado precisa ser limpo.

Para aperfeiçoar a natação, a piscina precisa ser limpa primeiro e depois enchida com água. Em resumo, são necessárias as condições certas.

Se a piscina estiver suja, ninguém vai querer competir. :)
 
Georgiy Merts:

Bem, ainda esta última semana eu tenho feito algumas modificações no algoritmo de avaliação da qualidade comercial para minha Liga TS. E estou muito feliz que tudo seja baseado em interfaces virtuais.

A questão é que antes do saque máximo foi estimado apenas pelo balanço. E eu queria fazer uma estimativa por Equidade. Mas para fazer isso, ao analisar o histórico - para cada transação é necessário solicitar as séries cronológicas, e ver qual foi o máximo de saque da transação, com base nos preços de então.

Agora lembre-se, que meu código é portátil, significa que baseado na mesma interface - tanto o MT4 como o MT5 funcionam. Assim, para cada plataforma - chama a classe apropriada com suas próprias funções, que são visivelmente diferentes. Assim, enquanto eu estava modificando o código - provavelmente uma dúzia de vezes eu estava em uma situação, quando não conseguia acessar diretamente os dados necessários - as interfaces não o permitiam. E cada vez que eu me certificava de que estava correto, que as interfaces tinham me limitado - se eu tivesse "mexido" com aqueles dados diretamente - isso teria causado erros em outras partes do programa. Os dados que eu precisava, eu tinha que acessar de uma maneira diferente, através de consultas adicionais, o que me permitia ter certeza de que nenhuma outra parte fosse afetada.

Em resumo: mais uma vez estou convencido de que o princípio "em cada lugar o usuário deve ter acesso somente àquelas estruturas que ele precisa no momento e nenhuma outra" é absolutamente correto. Você não deve deixar o usuário sempre ter acesso a tudo o que ele precisa - isso pode causar erros de modificação.

Mas, por outro lado - pessoas acostumadas a um estilo processual - simplesmente se limitam em tais casos, lembrando quais dados podem ser alterados de um determinado lugar e quais não podem.

Com todo respeito, mas seus argumentos são como os de um homem muito velho explicando e provando a necessidade do bastão em que ele se apoia. Sem ele, certamente vou cair. Isso é verdade. Mas não para todos.

 
Реter Konow:

Muito controverso)).

Talvez, mas eu também sou um "dinossauro do final dos anos 90" vi Turbo Pascal e os rudimentos dos gráficos na forma de bibliotecas que, não importa como você gira - você ainda tem o Norton Commander ))))

Mas com o advento (e minha transição) para Delphi, como eles dizem, foi lá que a vida começou.... Não consigo imaginar como fazer janelas ativas, caixas de seleção, etc. sem OOP, acho que em teoria, mas nem vejo como isso pode ser feito sem OOP, pois dizem que você se acostuma a uma coisa boa!

 
Реter Konow:

Com todo respeito, seus argumentos são como os de um homem muito velho explicando e provando a necessidade do bastão em que ele se apoia. Sem isso, estou destinado a cair. Isso é verdade. Mas não para todos.

Você, se bem me lembro, lembra perfeitamente tudo o que está em seu enorme conjunto de dados. Eu, por outro lado, não me lembrava de tais coisas, mesmo quando era jovem. Agora, quando sou um homem velho, certamente não consigo me lembrar de tudo o que quis dizer quando escrevi um determinado bloco. Este "pau" realmente me ajuda muito. Mas, concordo que se alguém é capaz de reter tudo o que é necessário em sua memória, ele pode passar sem isso.

No entanto, já citei várias vezes o respeitado código do fxsaber, onde ele mesmo não pôde me dizer exatamente como funciona. É só que tem verificações muito complicadas e não óbvias que são de fato difíceis de lembrar. E o homem não se lembra. O consenso foi que "este código foi verificado muitas vezes, portanto, ele pode ser confiável". Mas o que acontecerá se alguns protocolos de trabalho mudarem? O código torna-se imediatamente inválido e, neste caso - em vez de corrigir o que mudou - ele terá que ser reexaminado até que este mesmo lugar seja encontrado.

É para isto que servem estes "paus". Os produtos de software hoje em dia são tão complicados que é irrealista ter em mente todos os seus meandros. É por isso que várias técnicas são utilizadas (OOP é apenas uma delas).

Razão: