Programação OOP vs procedimento - página 35
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
Tenha cuidado, não estamos falando de variáveis de MT internas, estamos falando de variáveis de objeto internas que você isolou, impedindo a possibilidade de ler seus valores enquanto depura e escreve código...
É isso que estou dizendo - quando você depura uma EA - você não precisa das variáveis internas da MT?
Da mesma forma, neste caso, com o objeto do processador de comércio - se você estiver depurando, digamos, a metodologia de colocar pedidos em seu TS - por que você teria acesso às variáveis internas do processador de comércio?
Andrei é ainda mais clínico do que Peter ou Sansanych, você está perdendo seu tempo.
Os jovens precisam ser ensinados.
Além disso, talvez haja uma razão racional no que dizem meus oponentes. Se eu tivesse, digamos, uma memória como a de Peter, eu poderia não me incomodar com a OLP também.
É o mesmo em outros lugares - se alguns dados forem necessários - então este bloco tem que fornecer a interface apropriada.
É isso que eu quero dizer... Em vez de apenas ver o valor da variável requerida, você tem que pensar em como anexar uma interface adequada a ela e depois desengatá-la de volta. :)
Parece uma atividade para masoquistas na programação :)
Sim... você não recebe nada melhor do que uma piça :) A idéia é ter uma linguagem de programação adequada, para facilitar a depuração e a escrita de códigos com o mínimo de gestos, mas aqui temos uma situação completamente oposta...
Esta não é uma "situação oposta". É verdade que o OOP requer algum trabalho extra. No entanto, é mais do que compensado pela conveniência de apoio e modificação do sistema.
Aqui novamente - voltando ao processador comercial - ele é escrito e utilizado em muitos TSs. É o isolamento de seus internos do TS, e trabalhar somente através de uma interface virtual permite não pensar em quais variáveis estão nele e a que se igualam. Se forem detectados erros, eles estarão dentro do processador e será necessário corrigi-los dentro de uma classe real, não afetando as classes TS. Se o erro estiver no próprio TS, ele não afetará as variáveis do processador comercial.
O encapsulamento é na verdade uma técnica muito útil.
Sim... você não pode deixar de se perguntar o que há nele :) A idéia é ter uma linguagem de programação adequada, para facilitar a depuração e a escrita de códigos com o mínimo de gestos, mas aqui temos uma situação completamente oposta...
A depuração é facilitada precisamente pela divisão de responsabilidade em cada classe: cada classe é responsável por seu próprio conjunto de variáveis. Nenhuma outra classe tem o direito de mudar seus valores. Como resultado, a maioria dos problemas já está eliminada na fase de compilação. E o acesso a variáveis de qualquer lugar do programa pode ser comparado a uma dúzia de volantes em um navio.
Os jovens precisam ser ensinados.
Além disso, talvez haja uma base racional no que dizem meus oponentes. Se eu tivesse, por exemplo, uma memória como a de Peter, eu não me incomodaria com o OOP também.
1. Quanto a rentabilidade de seus assessores aumentou com o uso de OOPs?
2. Quanto a rentabilidade de seus assessores diminuiu com o uso do OOP?
É isso que eu quero dizer... Em vez de apenas ver o valor da variável requerida, você tem que pensar em como anexar uma interface adequada a ela e depois desengatá-la de volta. :)
Parece uma atividade para masoquistas na programação :)
Você vê, acima no assunto, Peter lhe mostrou uma de suas estruturas, não a maior.
Você pode descobrir isso facilmente?
Este mesmo "masoquismo" é exatamente o que permite, em primeiro lugar, não entrar no código de trabalho e não estragá-lo. E, em segundo lugar, permite que você projete imediatamente a estrutura do sistema para que possa fornecer os dados necessários nos blocos correspondentes do programa.
Sim, de fato, há situações em que de repente você percebe que é quase impossível obter os dados necessários. Elas estão escondidas atrás de várias interfaces virtuais. No entanto, esta situação mostra claramente que o sistema foi originalmente projetado incorretamente, não previa a transmissão destes dados. Esta situação é realmente muito desagradável. Temos que construir apressadamente "muletas" na forma de interfaces adicionais, ou reestruturar todo o sistema. Bem... Isto motiva o programador a pensar mais cuidadosamente sobre a arquitetura do sistema.
Se você tivesse menos emoção e reflexividade e mais especificidade na essência da discussão - você não valeria a pena. :)
Não há mais substância para esta discussão. Você está basicamente flubrificando e fingindo ser obtuso.
Se um moderador fecha as últimas páginas como irrelevante para o tópico do tópico e programação em geral - será um caso raro em que apoiarei suas ações.
1. Quanto a rentabilidade de seus EAs aumentou com o uso dos OOPs?
2. Quanto a taxa de falhas de sua EA diminuiu em quanto?
1. Não por quanto. A rentabilidade não depende do OOP.
2. Em minha opinião, por uma ordem de grandeza (dez vezes). Mas o principal ganho do OOP está no suporte ao código. Agora sou muito rápido em descobrir o código que escrevi há um ano ou mais. Lembro-me bem de como entendi meus primeiros programas ANSI C em estilo puramente processual. Foi muito mais difícil.
A depuração é facilitada precisamente pela divisão de responsabilidade em cada classe: cada classe é responsável por seu próprio conjunto de variáveis. Nenhuma outra classe tem o direito de mudar seus valores. Como resultado, a maioria dos problemas já está eliminada na fase de compilação. E o acesso a variáveis de qualquer parte do programa pode ser comparado a uma dúzia de volantes em um navio.
Não consigo entender porque NUNCA encontrei nada parecido em meu trabalho. Por que os problemas de delimitação de acesso variável por UM desenvolvedor em um programa não muito grande? Haveria 100 desenvolvedores, cada um escrevendo 100 funções. Teoricamente, ela poderia ser inventada. Mas praticamente a programação evoluiu para o OOP por quase 40 anos, montanhas de código foram escritas e nunca ouviram nada parecido.