Uma pergunta para os especialistas do OOP. - página 11
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
Se um programador entra no mundo do forex, não há necessidade de ser um profissional e conhecer o OOP.
É melhor aprender os meandros do mercado e desenvolver uma estratégia comercial lucrativa. E não importa se você usa OOP ou não. A rentabilidade do Expert Advisor não sofrerá com isso.
Você não precisa desperdiçar suas energias.
George, não se trata apenas de memória. Criei um ambiente de desenvolvimento confortável para mim mesmo, usando minha língua nativa e também o inglês. O código bilíngüe é lembrado MUITO melhor do que o código monolíngüe. Especialmente quando você não está preso a palavras padrão e chama variáveis por qualquer nome que você queira. Comprovado. Simplesmente ignorei o profissionalismo na programação e comecei a escrever como me agradou. Como resultado, comecei a navegar rapidamente meu código e a lê-lo, relembrá-lo e desenvolvê-lo facilmente. O resto você sabe...
Eu não acho que possa ajudar. Para mim os nomes das variáveis em qualquer idioma são apagados de minha memória quase que instantaneamente, eu me levanto de trás do computador e já me lembro apenas dos princípios gerais e não consigo dizer quais variáveis foram inseridas em qual lugar.
A propósito, é por isso que eu sempre uso pares de arquivos mqh-mq5 em vez de escrever classes inteiramente em arquivos mqh - eu preciso olhar os arquivos de cabeçalho freqüentemente, apenas para me lembrar o que está disponível em um ou outro caso, eu tenho os arquivos mqh de cabeçalho necessários abertos em abas, e eu mudo para eles quando preciso atualizar essas informações novamente. Quando classe inteira (e ainda mais várias classes) são descritas em um arquivo mqh, é mais difícil "saltar" através deste arquivo, mesmo com a ajuda de abas.
Não consigo manter toda a estrutura em minha memória, embora na minha juventude, como já mencionei, eu até escrevi em assembler, mas não há outras opções - você só tem endereços de memória, e o máximo que o macro assembler permite é criar nomes de áreas específicas usando macrossubstituições. Mas há muito tempo me convenci de que desta forma o número de erros é muito maior e a depuração de tal código é muito mais difícil.
Já dei um exemplo acima: um erro ocorre e uma variável é modificada incorretamente por algum motivo. E a variável é acessada de muitos lugares no programa. Como pegar um lugar onde há um erro? Com o encapsulamento OOP é muito simples - colocamos um ponto de parada na função de interface que modifica a variável, e assim que ocorre a modificação incorreta - paramos e imediatamente, pela hierarquia de chamadas, vemos onde a modificação incorreta foi feita.E com sua abordagem, Peter, temos que escavar todo o código, olhar todos os lugares onde esta variável é acessada, colocar pontos de parada em todos os lugares e analisar todas as chamadas, não apenas as incorretas.
É isso mesmo, ele pode sofrer. O amigo meu perdeu uma parte de seu depósito por causa de um erro em seu código, enquanto que o OOP torna os erros menos prováveis.
Isso significa que ele não é um bom programador. Você pode ficar mais confuso em construções OOP complexas do que sem elas.
As aulas devem ser aplicadas onde for necessário. Tenho notado que alguns programadores de alguma forma têm uma obsessão em aplicar muitas funções onde elas não são necessárias. Acontece da mesma forma com as aulas.
Em vez de escrever um programa compacto e curto sem OOP, alguns programadores começam a aplicar aulas, muitas funções e uma solução simples se transforma em um texto de um quilômetro de comprimento.
Isso significa que ele não é um bom programador. Você pode ficar mais confuso em construções OOP complexas do que sem elas.
Todas as outras coisas sendo iguais? Eu duvido muito. Se a complexidade das construções for a mesma, é muito mais fácil dar sentido a elas com o OOP.
Entretanto, não cancela a regra "com um canhão sobre um pardal", não faz sentido usar grandes complexidades do OOP onde a tarefa é muito simples e compacta.
Embora, como já foi dito aqui - o OOP nos permite construir bibliotecas de classe, que depois são utilizadas em muitos projetos.
Digamos, as mesmas classes de array, classes de arquivo... Mesmo quando você escreve um indicador muito simples, sem usar o OOP, é muito mais fácil declarar um Ficheiro de classe e usar suas funções, ao invés de usar as funções padrão de trabalhar com arquivos.Sem mencionar a possibilidade de substituir facilmente o CFile por outros mais específicos, por exemplo, eu tenho uma classe CLogFile com a capacidade de inserir automaticamente tempo e alguns dados adicionais em strings (para arquivos de log) ou classe CIniFile, que pode organizar os dados em arquivos ini padrão, e então lê-los e usá-los quando necessário.
Isso significa que ele não é um bom programador. Você pode ficar mais confuso em construções OOP complexas do que sem elas.
As aulas devem ser aplicadas onde for necessário. Tenho notado que alguns programadores de alguma forma têm uma obsessão em aplicar muitas funções onde elas não são necessárias. Acontece da mesma forma com as aulas.
Em vez de escrever um programa compacto e curto sem OOP, alguns programadores começam a aplicar aulas, muitas funções e uma solução simples se transforma em um texto de um quilômetro de comprimento.
Está tudo bem que o trabalho real seja uma centena de linhas, e o par de milhares restante é uma biblioteca escrita e depurada há muito tempo? )))
Se um programador usa classes prontas em seu programa, como estas: CTrade, CAccountInfo, CPositionInfo, isso não significa que seu programa é baseado no OOP.
Depende se o programador cria ele mesmo essas classes, ou simplesmente as utiliza sem conhecer os internos (no nível do texto fonte) dessas classes.
....
Um exemplo já foi dado acima - ocorreu um erro, por alguma razão uma variável é modificada incorretamente. E a variável é acessada de um monte de lugares no programa. Como pegar um lugar onde o erro ? Com o encapsulamento OOP é muito simples - colocamos um ponto de parada na função de interface que modifica a variável, e assim que ocorre a modificação incorreta - paramos e imediatamente, pela hierarquia de chamadas, vemos onde a modificação incorreta foi feita.E com sua abordagem, Peter, temos que escavar todo o código, olhando todos os lugares onde esta variável é acessada, colocando pontos de parada em todos os lugares e analisando todas as chamadas, não apenas as incorretas.
Sim, meu núcleo é modificado em todas as partes do programa e erros acontecem, mas eu não preciso de pontos de parada. Calculo em minha mente e alerto em vários lugares para verificar os valores. É assim que eu o encontro. Sublinho - conheço muito bem meu programa.
Mas, pelo lado positivo, com este conhecimento, sem obstáculos sintáticos e com uma língua nativa, tenho enormes oportunidades de desenvolvimento rápido. E é por isso que eu sou contra o OOP em minhas soluções.
Dividir o código, sua monolingualidade alienígena, nova sintaxe, regras adicionais - tudo isso retardará o desenvolvimento do programa. Vou perder mais esforço e obter menos resultados. Eu sei disso de fato.
Se minha tarefa fosse construir e depurar um programa a partir de peças de código prontas, somente o OOP e bibliotecas fariam. Engatar e desenvolver novas soluções são coisas diferentes. Muitas pessoas defendem o OOP porque querem usar pedaços do código de outras pessoas e poupar esforços. Eu crio minhas próprias soluções utilizando tecnologia própria e tenho diferentes necessidades e visões sobre o OOP.
Sim, meu núcleo é modificado em todas as partes do programa e erros acontecem, mas eu não preciso de pontos de parada. Calculo em minha mente e alerto em vários lugares para verificar os valores. É assim que eu o encontro. Sublinho - conheço muito bem meu programa.
Mas o lado positivo é que com tal conhecimento, ausência de obstáculos sintáticos e língua nativa, tenho enormes oportunidades de desenvolvimento rápido. E é por isso que eu sou contra o OOP em minhas soluções.
Dividir o código, sua monolingualidade alienígena, nova sintaxe, regras adicionais - tudo isso retardará o desenvolvimento do programa. Vou perder mais esforço e obter menos resultados. Eu sei disso de fato.
Se minha tarefa fosse construir e depurar um programa a partir de peças de código prontas, somente o OOP e bibliotecas fariam. Engatar e desenvolver novas soluções são coisas diferentes. Muitas pessoas defendem o OOP porque querem usar pedaços do código de outras pessoas e poupar esforços. Eu crio minhas próprias soluções utilizando tecnologia própria e tenho diferentes necessidades e visões sobre o OOP.
Aconselho usar o modelo de caixa de diálogo VC++ pelo menos uma vez, criar aplicativo baseado em CDialog do MFC, definir todos os tipos de controles sobre ele em modo visual, usar funções prontas para entender todo o poder do OOP.
E também gostaria de acrescentar que a Borland C++ tem aulas muito úteis para trabalhar com Oracle. Eu trabalhei com ele até 2012, não sei como agora.
Aconselho usar o modelo de caixa de diálogo VC++ pelo menos uma vez, criar aplicativo baseado em CDialog do MFC, definir todos os tipos de controles sobre ele em modo visual, usar funções prontas, para entender todo o poder do OOP.
E também gostaria de acrescentar que a Borland C++ tem aulas muito úteis para trabalhar com Oracle. Eu trabalhei com ele até 2012, não sei como agora.
é o segundo semestre de 2019.... mas tanto o 20º como o 25º e .... Também irá argumentar sobre a necessidade de usar o OOP?
))))
se gostamos, nós o usamos, se não gostamos, não o usamos.
se você se acostumou a escrever programas usando pequenas sub-rotinas previamente escritas - escreva, você se levantou do lado errado da cama... você coloca todas essas sub-rotinas no código fonte e recebe uma grande confusão de código
dar às pessoas muitas possibilidades do código aberto, ainda não é o mesmo, funcionalidade de aparar para C puro, mais uma vez não é o mesmo ))))
ZS: Suspeito que alguns dos desenvolvedores estão lendo o fórum de qualquer maneira... Acho que este fio vai com certeza animá-los! ))))