Uma pergunta para os especialistas do OOP. - página 10
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
E eu também - pouco a pouco... e a compreensão plena só vem depois de 4-5 anos (e isto é normal para uma pessoa comum)
Na minha opinião, não é necessário "compreensão plena". O principal é "agarrar a essência". Eu, quando conheci a meodologia OOP, foi em 1995.
Eu já tinha alguma experiência com "C regular" no espírito da K&R (oldfags devem se lembrar), além de ter usado funções de assembler com bastante freqüência. No início eu estava bastante cético sobre as idéias do OOP, não tanto porque o programador tinha que realizar algumas ações extras, mas por causa da "sobrecarga" pura da CPU. Mas logo fiquei convencido da utilidade desta tecnologia e aclasse CString foi o principal "interruptor" em minha mente.
Não só isso, mas trabalhar com cordas era muito mais simples: naquela época estávamos escrevendo um empacotador de dados e minha parte era o analisador de texto de entrada. Consequentemente, parecia ser muito conveniente criar uma hierarquia de várias cordas com base na classe CString, que tinha diferenças importantes para nosso embalador.
Gostei especialmente do fato de que depois que o empacotador de dados foi escrito, surgiu a tarefa de utilizá-lo para cordas, que tinha muitas informações digitais, para as quais o empacotador não foi originalmente projetado. Certamente embalou tais dados, no entanto, fez isso considerando o alfabeto de entrada como apenas caracteres, mas sabendo que a cadeia consiste em algumas palavras e dígitos - melhorou significativamente o embalador sem perda de velocidade. Assim, uma classe representando tais cadeias com dígitos (e também um compressor específico para dígitos) foi escrita, tudo foi adicionado às classes existentes e o embalador começou a trabalhar com novos dados, embora esta funcionalidade não fosse esperada inicialmente.
Foi quando eu realmente apreciei o potencial do OOP para modificar e manter o código. É claro que há algumas despesas gerais de CPU, mas isso é mais do que compensado pelo trabalho reduzido dos programadores.
É por isso que recomendo a todos que começam a aprender o OOP que comecem com tais tarefas, onde a vantagem do OOP seria bem e claramente visível. Ou seja, com as tarefas de processar diferentes objetos em listas, o que representaria instâncias de classes com um antepassado comum.Olhe, tenho este canal em minhas assinaturas, em geral tenho uma opinião positiva do autor, e há até uma repetição do tópico de seu vídeo para o qual a discussão começou:
Há um par de pequenas objeções e esclarecimentos (por exemplo, considero o NULL como um ponteiro muito útil, que fala de um erro, basta ter em mente que a função pode retornar este ponteiro nulo e, claro, o vídeo diz corretamente - você não pode trabalhar com ele como com um objeto).
E tudo o mais sobre imprecisões, ordem de desenvolvimento, getter-setters e o mesmo NULL está correto.
Kudos ao autor.
É estranho que, sendo uma pessoa filosófica e bem abstraída, estou tão desesperada para rejeitar a abordagem amada do profissional à programação. Embora tenha sido projetado para ser prático, o OOP se tornou superprotegido com entidades e redundante para suas tarefas. A "redundância" de ferramentas dificulta a solução, assim como a escassez. E esta redundância é sem dúvida uma conseqüência do marketing. Pense nisso, um OOP mínimo é suficiente para resolver tudo no campo dos problemas informáticos. Da mesma forma que tudo pode ser criado com funções simples e com o manejo adequado da memória. No nível inicial, eu adotei imediatamente o OOP. Então notei que algumas entidades não puderam justificar a necessidade de sua existência e viveram suas próprias vidas, abstraídas de tarefas, dentro do conceito crescente. Sim, eles se integram às soluções, mas parasitam a inteligência do desenvolvedor. Eles retardam o processo de trabalho, reduzindo sua eficiência. Eles dificultam o fluxo de trabalho por ofuscação, sintaxe, regras... É disso que não gosto nesta opcionalidade dentro da solução.
Portanto, vou usar o OOP mais mínimo possível. Aquela que foi criada antes de ser comercializada.
É estranho que, sendo uma pessoa filosófica e bem abstraída, estou tão desesperada para rejeitar a abordagem amada do profissional à programação. Embora tenha sido projetado para ser prático, o OOP se tornou superprotegido com entidades e redundante para suas tarefas. A "redundância" de ferramentas dificulta a solução, assim como a escassez. E esta redundância é sem dúvida uma conseqüência do marketing. Pensando bem, um OOP mínimo é suficiente para resolver tudo no campo dos problemas informáticos. Da mesma forma que tudo pode ser criado com funções simples e com o manejo adequado da memória. No nível inicial, eu adotei imediatamente o OOP. Então notei que algumas entidades não puderam justificar a necessidade de sua existência e viveram suas próprias vidas, abstraídas de tarefas, dentro do conceito crescente. Sim, eles estão incorporados às soluções, mas são parasitas da inteligência do desenvolvedor. Eles retardam o processo de trabalho, reduzindo sua eficiência. Eles dificultam o fluxo de trabalho por ofuscação, sintaxe, regras... É disso que não gosto nesta opcionalidade dentro da solução.
Portanto, vou usar o OOP mais mínimo possível. Aquela que foi criada antes de ser comercializada.
Sim. Você cria uma classe, por exemplo, para trabalhar com um arquivo. Você começa a usá-lo e recebe bugs. Você fecha uma parte do código e tenta fazer algo com ela na outra parte. Há duas abordagens. A primeira é tentar sempre lembrar onde algo é feito e mesmo com um desenvolvedor isso pode não ser muito bom. A segunda - antes da ação de verificação das operações a fazer. Certo, o próximo erro: em operações de verificação, que estão espalhadas pelo código, aqui e ali digitação, sinal errado, corrigido em um lugar, esquecido em outro, etc. Como resultado, você passou de uma eficiência de código tão amada para uma coisa trivial e simples: cada método de leitura/escrita e assim por diante tem uma chamada para um método de verificação com uma opção para desfazer esta chamada, que você quase nunca usará. E então você percebe que isto é uma coisa boa, porque o hardware moderno permite que você não conte os ciclos do relógio e o consumo de memória em 98% das tarefas resolvidas.
Sim. Você cria uma classe, por exemplo, para trabalhar com um arquivo. Você começa a usá-lo e recebe bugs. Você fecha uma parte do código e tenta fazer algo com ela na outra parte. Há duas abordagens. A primeira é tentar sempre lembrar onde algo é feito e mesmo com um desenvolvedor você pode falhar em fazer isso.
Peter é bom nisso.
Esse é o problema - Peter se sente confortável usando uma tabela enorme de todas as variáveis, que está sempre disponível em todo o programa, e da qual ele tira o que precisa a qualquer momento. Para o titã da memorização, isto é bastante útil.
No encapsulamento OOP é um recurso de arquivo, que é usado apenas para garantir que o usuário em qualquer parte do código só tenha acesso às variáveis que ele precisa e a nenhuma outra variável. Mas para Peter é um menos, ele já se lembra onde, o que e como ele usou. Ele quer poder acessar qualquer variável em qualquer parte do programa a qualquer momento. Ele não gosta da minha abordagem, quando para acessar uma variável é preciso primeiro obter um ponteiro para a interface, e da interface é preciso obter a função, e só então ela retorna o valor que você precisa. E em qualquer uma destas etapas, você pode encontrar restrições de acesso. Acho que isto é uma coisa boa, porque se existe uma restrição - ela é colocada por uma razão, significa que eu não considerei alguns detalhes importantes. E para Peter, é um obstáculo, porque ele sempre leva tudo em conta.
Sim, você criou uma classe para lidar, digamos, com um arquivo. Você começa a usá-lo e recebe erros. Você fecha uma parte do código e tenta fazer algo com ela na outra parte. Há duas abordagens. A primeira é tentar sempre lembrar onde algo é feito e mesmo com um desenvolvedor isso pode não ser muito bom. A segunda - antes da ação de verificação das operações a fazer. Certo, o próximo erro: em operações de verificação, que estão espalhadas pelo código, aqui e ali digitação, sinal errado, corrigido em um lugar, esquecido em outro, etc. Como resultado, você passou de uma eficiência de código tão amada para uma coisa trivial e simples: cada método de leitura/escrita e assim por diante tem uma chamada para um método de verificação com uma opção para desfazer esta chamada, que você quase nunca usará. E então você percebe que isto é uma coisa boa, porque o hardware moderno permite que você não conte os ciclos do relógio e o consumo de memória em 98% das tarefas resolvidas.
Vamos imaginar a situação oposta. Bem, você não tem insetos. De forma alguma e quase nunca, porque você se lembra de TUDO e leva TUDO em conta! Vocêusaria o OOP apenas por causa de seu "dever profissional"? Acho que não. Com o que você se importaria então? - Somente a eficiência de seus códigos. Você tentará remover todas as despesas gerais, para que o código funcione o mais rápido possível. Você também tentará criar seu código de tal forma que ele se desenvolva rapidamente.
Quando as pessoas me falam sobre insetos que ocorrem aqui e ali eu os entendo, mas quando eles estão associados ao uso ou não uso do OOP eu não concordo. O número de bugs depende do conhecimento e da compreensão do código. Quem escreve o código o conhece melhor do que uma pessoa que o conecta. Quem o escreve tem sempre menos bugs. Como você entende, o OOP promove a portabilidade do código cujo lado oposto é pouco compreendido por outros programadores. Essa é a fonte dos insetos.
Eu mesmo escrevo tudo, e encontro bugs em blocos de 2000 linhas sem funções de perfil e checagem. Simplesmente, eu conheço meu código. A melhor cura para os insetos)).
Funciona para Peter.
Esse é o problema - Peter se sente confortável usando uma tabela enorme de todas as variáveis, que está sempre disponível em todo o programa, e da qual ele tira o que precisa a qualquer momento. Para o titã da memorização, é bastante útil.
O encapsulamento no OOP é um recurso de arquivo, que é usado precisamente para garantir que o usuário tenha acesso apenas àquelas variáveis que ele precisa em qualquer lugar de código, e não mais. Mas para Peter é um menos, ele já se lembra onde, o que e como ele usou. Ele quer poder acessar qualquer variável em qualquer parte do programa a qualquer momento. Ele não gosta da minha abordagem, quando para acessar uma variável é preciso primeiro obter um ponteiro para a interface, e da interface é preciso obter a função, e só então ela retorna o valor que você precisa. E em qualquer uma destas etapas, você pode encontrar uma restrição de acesso. Acho que isto é uma coisa boa, porque se existe uma restrição - ela é colocada por uma razão, significa que eu não considerei alguns detalhes importantes. E para Peter, é um obstáculo, porque ele sempre leva tudo em conta.
George, não se trata apenas de memória. Criei um ambiente de desenvolvimento conveniente para mim, usando minha língua materna e inglês também. O código bilíngüe é MUITO melhor para lembrar do que o 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. Além disso, você sabe...
ZS. Não deixe que eles pensem que estou me importando com o profissionalismo. Absolutamente não. Eu cuspo nele por causa de meu ego inflado demais. Acontece que não só pode ser ruim, mas também bom. :)
Peter, seu pensamento sugere que você nunca trabalhou em equipe. Você ainda não viu como cada um faz sua própria parte de uma enorme tarefa, e como tudo isso se junta no final.
Por exemplo, sem o OOP, era impossível criar e desenvolver Windows.
Se não fosse necessário, eu também tentaria não aplicar classes. Mas quando decidi transformar meu robô em um robô de múltiplas moedas, imediatamente apliquei as classes, porque já estava claro o que aconteceria sem o OOP.
Ao aplicar classes, é óbvio que os pares de objetos utilizados são da mesma classe e trabalhar com eles simultaneamente já é muito fácil.
Peter, seu pensamento sugere que você nunca trabalhou em equipe. Você ainda não viu como cada um faz sua própria parte de uma enorme tarefa e como tudo se une no final.
Por exemplo, sem o OOP, era impossível criar e desenvolver Windows.
Se não fosse necessário, eu também tentaria não usar classes. Mas quando decidi transformar meu robô em um robô de múltiplas moedas, imediatamente apliquei as classes, porque já estava claro o que aconteceria sem o OOP.
Ao aplicar classes, é óbvio que os pares de objetos utilizados são da mesma classe e trabalhar com eles simultaneamente já é muito fácil.
Sim, eu não fazia parte da equipe. Minha abordagem deve ser considerada como uma experiência de um desenvolvedor. Não estou convencendo a segui-lo. Há demasiada impertinência em minha abordagem).
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.