Programação OOP vs procedimento - página 27
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
Na programação funcional-processal, os problemas de acesso que você descreve não existem. Sem sobrecarregar funções, sem campos e objetos, sem ponteiros e outras coisas, quando você só tem uma memória para todas as variáveis globais que você pode acessar de qualquer lugar, como pode ser chamada a função errada? Que tipos de erros de acesso podem ocorrer? E é muito mais fácil lembrar de tudo.
É um simples erro - referir-se à variável errada contendo um valor próximo em valor.
Tal erro pode não ser detectado por muito tempo, mas, pela lei da mesquinhez, ele "aparece" justamente no momento em que o trabalho sem erros neste lugar seria muito necessário!
E vai ser tão difícil de descobrir... Você está tentando entender por que o Expert Advisor fechou um negócio em uma boa tendência quando o TS não deveria tê-lo fechado - e você não pode. Tudo parece estar funcionando corretamente.
Este é exatamente um dos erros mais desagradáveis - não-inicialização de variáveis, ou endereçar a variável errada, mas próxima do valor. E quanto mais variáveis estiverem disponíveis nesta ou naquela parte do programa - maior é a probabilidade deste erro.
Sim, claro, se você tem um núcleo gráfico acessível globalmente, e trabalha com pedidos, é realmente difícil acessar a variável errada. Mas em um bloco anterior onde se detecta a necessidade de abrir um pedido e indicadores de endereço para este fim e provavelmente de acordo com as ações do usuário - é bem possível misturar variáveis.
Se houver mais estruturas, e detalhes importantes desaparecerem periodicamente da memória - você chegará à conclusão de que o acesso global - é uma fonte de problemas, e você deve evitar usá-lo a qualquer custo. E que o código deve ser escrito de tal forma que você se lembre o mínimo possível. Idealmente, não manter nada na memória - cada bloco tem um nome, indicando sua função, na entrada recebe dados necessários e suficientes para esta função, tudo o que resta é implementar a função sem envolver qualquer outro conhecimento "de fora".
É um simples erro - referir-se à variável errada contendo um valor próximo em valor.
Tal erro pode não ser detectado por muito tempo, mas, pela lei da mesquinhez, ele "aparece" justamente no momento em que o trabalho sem erros neste lugar seria muito necessário!
E vai ser tão difícil de descobrir... Você está tentando entender por que o Expert Advisor fechou um negócio em uma boa tendência quando o TS não deveria tê-lo fechado - e você não pode. Tudo parece estar funcionando corretamente.
Este é exatamente um dos erros mais desagradáveis - não-inicialização de variáveis, ou endereçar a variável errada, mas próxima do valor. E quanto mais variáveis estiverem disponíveis nesta ou naquela parte do programa - maior é a probabilidade deste erro.
Sim, claro, se você tem um núcleo gráfico acessível globalmente, e trabalha com pedidos, é realmente difícil acessar a variável errada. Mas em um bloco anterior onde se detecta a necessidade de abrir um pedido e indicadores de endereço para este fim e provavelmente de acordo com as ações do usuário - é bem possível misturar variáveis.
Se houver mais estruturas, e detalhes importantes desaparecerem periodicamente da memória - você chegará à conclusão de que o acesso global - é uma fonte de problemas, e você deve evitar usá-lo a qualquer custo. E que o código deve ser escrito de tal forma que você se lembre o mínimo possível. Idealmente - não armazenar nada na memória - cada bloco tem um nome, indicando sua função, ao receber os dados necessários e suficientes para esta função, resta apenas implementar a função, não envolvendo nenhum outro conhecimento "de fora".
Bem, como você pode chamar a variável errada, se todos eles têm nomes diferentes? Como se pode chamar uma função errada se ela tem um nome único e sem sobrecarga? Dentro da matriz do núcleo todos os índices de células são nomeados com palavras humanas. O que pode ser confundido aqui? Entenda que os problemas de que você está falando não existem de forma alguma.
Eu só mantenho a estrutura do núcleo na memória, o que é muito simples. Eu também conheço a lista de propriedades dos objetos. Todos os objetos têm as mesmas propriedades, apenas os valores são diferentes. Tenho um total de 140 propriedades, mas guardo na memória apenas as mais importantes, cerca de 30. O resto eu me lembro quando preciso deles. Para fazer isso, abro um arquivo com definições e vejo a lista completa de propriedades. Nada complicado. As variáveis globais em foco, como por exemplo "OBJETO" ou "JANELA", não precisam ser lembradas de forma alguma. E é impossível misturá-lo com qualquer outra coisa.
Minhas variáveis têm nomes significativos em russo. Você só pode confundir as coisas depois de uma festa selvagem).Minhas variáveis globais são as variáveis utilizadas em foco, que são "direcionadas" para o núcleo e movimentadas à medida que o cursor se move.
Por exemplo: a variável "WINDOW" carrega constantemente o número da janela na qual o cursor está localizado. A variável "OBJETO" é o número daquele objeto onde se encontra o cursor.
Abordo uma determinada janela, objeto e propriedade no núcleo através deles - G_CORE[WINDOW][OBJECT][_NAME] ou G_CORE[WINDOW][OBJECT][_OBJECT_GROUP]. Em qualquer função, se eu precisar da X-coordenação de um objeto, eu a obtenho de G_CORE[WINDOW][OBJETO][_X], se a altura do objeto - de G_CORE[WINDOW][OBJETO][_Y_SIZE] etc...
Ao todo, tenho cerca de uma centena de variáveis globais declaradas separadamente, mas há milhares delas na matriz global do kernel, porque cada célula da matriz é uma variável. Entretanto, é muito fácil administrar este número de variáveis, pois elas são encomendadas. Cada janela no núcleo é um campo de array; cada linha é um objeto, que consiste em 140 propriedades. Os elementos, neste caso, são conjuntos de objetos. Cada elemento tem um objeto mestre, que contém as principais propriedades de todo o elemento. Os objetos pertencentes a cada elemento estão ligados por índices especiais, portanto, qualquer que seja o objeto em foco, o elemento ao qual ele pertence também entra em foco. Assim como a tela sobre a qual é desenhado. Graças ao arquétipo explícito do kernel e acesso direto de qualquer função, posso gerenciar milhares de variáveis que são representadas pelas células da matriz do kernel sem esquecer nada e sem ter que navegar ao redor delas.
Uma conversa completamente inútil: não há critério para classificar o código como "bom" ou "ruim". É por isso que não está claro sobre o OOP.
Para mim, tal critério é a FACILIDADE do código, que se manifesta no fato de que o autor ou um terceiro pode ler o código e usá-lo para modificação, procurando por bugs após um longo período de tempo.....
Aqui acima Fedoseyev substituiu a chave OOP. Este exemplo particular, talvez lamentável, para mim é uma prova da maldade do OOP: código claro com um interruptor de 100 posições é substituído por uma única linha. Para entender esta linha, você tem que ir a algum lugar. Não é permitido para mim.
O segundo exemplo acimapor George Merts
Quando o código claro foi substituído pelo código NÃO claro após a depuração. Pelo meu critério o código de qualidade (fácil de ler) foi substituído pelo código que não é aceitável para mim.
É por isso que tenho uma pergunta para todos os apoiadores da OOP: um programa se torna mais vivo quando a OOP é aplicada e o exemplo dado por Fedoseyev no interruptor é um fracasso ou, pelo contrário, o exemplo de Fedoseyev caracteriza com muita precisão a OOP e a OOP quase sempre leva a uma perda de vividez?
Bem, tudo está claro com a CC. Tudo acima do nível de sua compreensão é inestético. Mas ele conhece a carta R ))))))))))))))
Bem, o CC é claro. Qualquer coisa acima de seu nível de compreensão é pouco atrativa. Mas ele conhece a carta R ))))))))))))))
Vou acrescentar chinês, talvez japonês...
Por que OLP? Por que seria melhor?
Visibilidade é a simplificação da depuração, modificação. A visibilidade vem do desenho cuidadoso do programa, da estruturação em FUNÇÕES e não em OBJETOS, porque o mundo inteiro se baseia em ações sobre objetos, mas não o contrário.
Quando a divisão em funções é derivada da seqüência de conversão de entradas em saídas. Por exemplo, a conversão de uma entrada BUY|SELL em uma saída só é possível especificando uma AÇÃO.
É assim que funciona o pensamento humano.
PS.
A respeito de seu comentário sobre o R.
Você quer ser sarcástico?
Eu respondo muito raramente, mas eu posso.
Como diabos você pode chamar a variável errada se todos eles têm nomes diferentes? Como se pode chamar a função errada se ela tem um nome único e sem sobrecarga? Dentro da matriz do núcleo, todos os índices de células são nomeados com palavras humanas. O que pode ser confundido aqui? Entenda que os problemas de que você está falando não existem de forma alguma.
Bem, já tive alguns desses casos.
Na maioria das vezes, tais erros ocorrem quando você copia um pedaço de código de outro lugar e o "conserta" de acordo com o bloco atual. Se você tem acesso global - você pode muito bem perder a mudança de uma das variáveis. Se você só tem acesso ao que você tem que trabalhar neste caso - então depois de copiar - o próprio compilador lhe dá uma lista de todas as variáveis e locais que precisam ser alterados.
Tag Konow:
Eu só tenho a estrutura do núcleo em minha memória, que é muito simples. Também conheço a lista de propriedades dos objetos. As propriedades de todos os objetos são as mesmas, apenas os valores são diferentes. Tenho um total de 140 propriedades, mas guardo na memória apenas as mais importantes, cerca de 30. O resto eu me lembro quando preciso deles. Para fazer isso, abro um arquivo com definições e vejo a lista completa de propriedades. Nada complicado.
30 propriedades ??? Bem, isso é inaceitável para mim. Não que eu não consiga me lembrar deles, mas não quero confiar na minha memória. Muito melhor, quando em cada bloco - você sempre tem exatamente essas variáveis, que neste bloco devem ser processadas, e não há acesso a outras.
Mas, isso me faz pensar em ter que lembrar... E já que não é difícil para você - é compreensível que não adianta fazer uma manipulação desnecessária do OOP.
Bem, já tive alguns desses casos.
Na maioria das vezes, erros deste tipo ocorrem quando você copia um pedaço de código de outro lugar e o "conserta" para combinar com o bloco atual. Se você tem acesso global, você pode muito bem perder a mudança de uma das variáveis. Se você só tem acesso ao que precisa trabalhar, então, após a cópia, o compilador lhe dá uma lista de todas as variáveis e locais que precisam ser alterados.
30 propriedades ??? Bem, isso não é aceitável para mim. Não é que eu não consiga me lembrar deles, mas não quero confiar na minha memória. Muito melhor, quando em cada bloco - você sempre tem exatamente essas variáveis, que neste bloco devem ser processadas, e simplesmente não há acesso a outras.
Mas, isso me faz pensar em ter que lembrar... E como não é difícil para você - é compreensível que não haja necessidade de fazer transações desnecessárias de OOP.
Bem, francamente falando, eu me lembro de muitas coisas. Basta ver as abreviações dos objetos de snapping _X2X, Y2Y, B2B, R2R, H2Y, W2X, Y2H, X2W, C2C etc... cada um define a posição de um objeto em relação ao outro. Estes são encontrados nos parâmetros A1,B1,C1,A2,B2,C2,A3,B3,C3,A4,B4,C4,A5... Também me lembro de algumas dezenas de nomes de categorias e subcategorias de objetos, algumas dezenas de propriedades de janelas (mais de 100 delas). Há dezenas de funções no bloco de construção, por exemplo, e elas ocupam mais de 4000 linhas de código. Você tem que navegar e se lembrar de muitos deles. Mas a lembrança vem de uma longa prática, não de uma vez, mas gradualmente. Minha cabeça costumava ficar pesada com a quantidade de entidades e o tamanho do código, mas depois tudo ficou amontoado e se tornou simples.
Bem, francamente falando, eu me lembro de muitas coisas. As abreviações das referências dos objetos _X2X, Y2Y, B2B, R2R, H2Y, W2X, Y2H, X2W, C2C, etc... Cada um define uma certa posição de um objeto para outro, estão nos parâmetros A1,B1,C1,A2,B2,C2,A3,B3,C3,A4,B4,C4,A5... Também me lembro de algumas dezenas de nomes de categorias e subcategorias de objetos, algumas dezenas de propriedades de janelas (mais de 100 delas). Há dezenas de funções no bloco de construção, por exemplo, e elas ocupam mais de 4000 linhas de código. Você tem que navegar e se lembrar de muitos deles. Mas a lembrança vem de uma longa prática, não de uma vez, mas gradualmente. Minha cabeça costumava inchar com o número de entidades e o tamanho do código, mas depois tudo se atolou e se tornou simples.
Para me distrair, esquecendo tudo, ir de férias por um mês sem pensar no código. Depois volte, veja todos estes a1, b1, etc. e fique histérico :)
se distrair, esquecer de tudo, sair de férias por um mês, sem pensar no código. Depois de vir, veja todos esses a1, b1, etc. e ficar histérica :)
Por exemplo, é assim que o elemento "checkbox" no proto-core se parece: