Interessante assumir a OLP - página 2
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
Que reação destrutiva ao tema e uma discussão destrutiva. Diga-me um seguidor de programação de procedimentos como evitar a "esparguetetização" no OOP, como analisar e se faz sentido usar o "esparguete" de outra pessoa?
Afinal, o que acontece é que o OOP é principalmente para a legibilidade e programação em equipe, ou seja, para grandes projetos. Um Expert Advisor que comercializa um símbolo em seu gráfico com o controle do risco máximo do saldo / fundos na conta, bem, não pode ser chamado de um grande projeto - é suficiente e mais rentável na memória / velocidade - programação de procedimentos.
Perguntas:
- desvantagens/vantagens do OOP(como imperativo) a partir da experiência pessoal
- desvantagens/vantagens do PF (como declarativo) a partir da experiência pessoal.
E uma opinião sobre as perspectivas é naturalmente interessante, especialmente na direção da computação paralela. Não vejo nenhum sentido em tocar no tópico quântico.
Preciso ver de onde veio, não entendo de todo o que há em poupar.
Uma boa característica de qualquer código é ter funções tão curtas quanto possível. É melhor que você tenha mais deles.
Por exemplo, metade das propriedades do OOP são coisas que gostaríamos de separar para a usabilidade - por exemplo, separar várias funções em um grupo e dar-lhes suas próprias variáveis que viveriam em seu namespace).
Como estamos trabalhando com um tipo de armazenamento "classe", podemos claramente pré-definir todas as variáveis para dar-lhes um certo tipo....
é conveniente criar um API externo. Você pode trabalhar com referência de classe (8 bytes) quando estiver trabalhando - muito utilizado.
Exemplo: Todos os tipos de listas de nódulos interligados e outras coisas.
// aqui só escrevi peculiaridades que vejo, é claro que não faz sentido escrever sobre possibilidades e propriedades de métodos protegidos e outras coisas.... isso é apenas açúcar.
Propriedades da FP é o que gostaríamos de fazer em algum lugar, depois de algo, por exemplo, gostaríamos de compor uma nova função na função - dividir a função atual, que usaria algumas das variáveis atuais de nossa função. Para passar sua execução para outra função - acontece que nós apenas passamos a função retardada, o cálculo que ainda não ocorreu - como um pedaço de código....
Na verdade, isto é bastante conveniente.
Isto deixa a propriedade de desenrolar o código completo porque de fato sabemos claramente qual a função que temos - o que provavelmente será mais rápido nos cálculos do que o OOP. Você pode organizar transferências bastante inteligentes de cálculos de uma função para outra - também a função lembra completamente o ambiente das chamadas variáveis da função passada - o que é muito legal (embora na verdade seja apenas salvar variáveis declaradas do escopo externo). FP, por outro lado, você pode definir o endereço de uma função e armazená-lo em uma matriz como uma classe - embora não seja particularmente útil.
Código fácil de escrever para ações atrasadas, todos os tipos de funções assíncronas, cálculos paralelos
Deixe-me explicar minhas preocupações com base no artigo citado e no próprio conceito de determinismo. O que me assusta na "esparguetetificação" (a complexidade do próprio código e a tarefa de encontrar erros de cálculo)? Então qual é a ênfase no artigo - valores "lixo" em variáveis ou retornos não-determinísticos de funções.
Construo/treino redes neurais de minha própria estrutura variável (evoluir). E para eles é muito crítico que o "lixo" em valores surja do nada.
Como no artigo - você pressiona o pedal do freio, e o pedal não quer saber de você. Isso está em uso. E se no estágio inicial de construção (seleção automática de arquitetura) e treinamento de seu "lixo" de rede neural for possível - como ele é construído/treinado?
Como evitar ao máximo o "lixo" (não-determinismo) no OOP?
Deixe-me explicar minhas preocupações com base no artigo citado e no próprio conceito de determinismo. O que me assusta na "esparguetetificação" (a complexidade do próprio código e a tarefa de encontrar erros de cálculo)? Bem, é nisso que o artigo enfoca - valores "lixo" em variáveis ou retornos não-determinísticos de funções.
Eu construo/treino redes neurais de minha própria estrutura de variáveis. E para eles é muito crítico que o "lixo" em valores surja do nada.
Como no artigo - você pressiona o pedal do freio, e o pedal não quer saber de você. Isso está em uso. E se no estágio inicial de construção (seleção automática de arquitetura) e treinamento de seu "lixo" de rede neural for possível - como ele é construído/treinado?
Como evitar ao máximo o "lixo" (não-determinismo) no OOP?
O artigo em geral é um tanto estranho, o homem esqueceu claramente de especificar o tipo de variável constante, como se ele tivesse js então pelo menos só de leitura. Depois disso ele escreve que supostamente teve um erro quando o objeto que não deve mudar o tamanho (ser uma constante) não é de alguma forma uma constante ..... e com base nisso ele conclui que há muita probabilidade de um erro no OOP)))
Em geral, o OOP permite que você controle áreas de variáveis. O OOP é projetado como uma transferência de variáveis de uma função, ou seja, já deveríamos ter um tipo padrão porque provavelmente há poucos deles. E, se necessário, esta função pode ser expandida rapidamente.
Isto é, no OOP há mais controle inicial
É isso aí, eu sempre suspeitei)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23Eu não sei quem escreve tais "artigos", palavras vazias, frases gerais, senso mínimo.
" O código como um todo era confuso e confuso - o que é chamado de "esparguete" na gíria " - por causa dos maus programadores daToyota, vamos considerar que noOOP o código é confuso.
" As características do OOP embutido só contribuem para aumentar a confusão. " - bem lógica, a capacidade de usar recursos acrescenta confusão ao código, com um aumento constante do número de recursos OOP (C#) será impossível escrever mais código simples. Sim.
"Na maioria das línguas orientadas a objetos, os dados são passados por referência, ou seja, diferentes partes do programa podem lidar com a mesma estrutura de dados - e modificá-la. Isto transforma o programa em um grande pedaço de estado global e contradiz a idéia original do OOP " - Eprivado,protegido?
"...Se você não gosta desta citação, é porque o não-determinismo em geral não o leva a lugar nenhum."Bem, sim, as funções imprevisíveis GetMicrosecondCount, MathRand, CoptBuffer, todas as funções da rede e outras devem ser jogadas fora porque o resultado lá depende do estado externo. É horrível.
Pronto, já chega, tudo está claro aqui.
Aí está, sempre suspeito)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23A maioria dos argumentos lá são sugados de seus dedos. Algumas experiências "provando" a invalidade do OOP estão incorretas em tudo. Em idiomas OOP normais a soma(int a, int b) será sempre limpa, mesmo que você escreva bobagens como a += b internamente. Novamente, se um objeto é alocado em pilha dentro de um método, ele é sempre protegido, porque somente o método que o chamou tem uma referência a ele. Você pode mudá-lo à vontade. Existem tipos de referência e significativos. Ninguém impede que você escreva funções limpas sem nenhum efeito colateral nos idiomas OOP. As funções matemáticas padrão são assim, por exemplo. Sim, às vezes não se pode passar sem recursos compartilhados, mas há coletas seguras para os fios e muito mais. Afinal, qualquer PF puro interagirá inevitavelmente com IO, BD, solicitações de rede e muitas outras coisas, que é onde os demônios de modificabilidade irão romper.
Artigo estranho....
A quantidade tende a se transformar em qualidade.
Quando há muitos rádios, pode haver incompatibilidade eletromagnética e eles deixarão de funcionar.
As propriedades do esparguete de código são geralmente de quantidade e não levam em conta todas as propriedades do invólucro quando há muitos usos em diferentes estados.
Em funções, a presença de feedbacks levará à mesma coisa. A histerese é uma brincadeira)
Entender os problemas e acertá-los ... ))))
// Apenas descrevi as características que posso ver aqui, obviamente não faz sentido escrever sobre a possibilidade e as propriedades dos métodos protegidos e assim por diante.... isso é apenas açúcar.
Propriedades de FP é o que gostaríamos de fazer em algum lugar, depois de algo, por exemplo, gostaríamos de compor uma nova função na mosca em uma função - compartilhar a função atual, que usaria algumas das variáveis atuais de nossa função. Para passar sua execução para outra função - acontece que nós apenas passamos a função retardada, o cálculo que ainda não ocorreu - como um pedaço de código....
Na verdade, é bastante conveniente.
Bem, quem impede de fazer o mesmo no OOP? Mesmo em uma linguagem puramente processual? Você passa um ponteiro para uma função para outra função e recebe execução atrasada.
Em geral, a assincronia é um padrão de design puro. Você também pode escrever código assíncrono em C puro. Você só precisa fazer uma máquina estatal que execute a tarefa em partes. A propósito, eu o fiz com indicadores em MQL que demoraram muito tempo para serem calculados. Fiz isso para evitar retardar o gráfico e exibir uma barra de status agradável que muda sua porcentagem de cumprimento.
Bem, quem o impede de fazer o mesmo no OOP? Mesmo em uma linguagem puramente processual? Você passa um ponteiro para uma função para outra função e consegue uma execução atrasada.
Em geral, a assincronia é um padrão de design puro. Você também pode escrever código assíncrono em C puro. Você só precisa fazer uma máquina estatal que execute a tarefa em partes. A propósito, eu o fiz com indicadores em MQL que demoraram muito tempo para serem calculados. Isso me ajuda a não desacelerar o gráfico e exibir uma barra de status agradável que muda sua porcentagem de implementação.
) Você também pode utilizar o assembler. A questão é onde é mais fácil.
E não me coloquem em um ou outro lado.... Eu não sou um pauzinho para uma coisa ou outra.
Artigo estranho. O OOP não difere do estilo de procedimento para pior, porque nele você pode fazer tudo em estilo de procedimento por padrão, e vice-versa sem um terrível inchaço de código, ou seja, o OOP é uma "superestrutura sobre", não um estilo fundamentalmente diferente.
Se o artigo é realmente sobre funcionalidade e não sobre procedimento (o que não é tão óbvio se você se meter nele), então por que comparar coisas que têm usos completamente diferentes.
Topeka starter, você mesmo está escrevendo e agora falando sobre qual? funcional ou processual?
Afinal de contas, o que acontece é que o OOP é principalmente para a legibilidade e programação de equipe, ou seja, para grandes projetos.
Eu não sei como usar o OOP. Mas eu utilizo coisas primitivas dela. Do passado recente, postou um código muito simples.
Comecei a escrevê-lo na FP, quando não entendia o que eventualmente precisaria ver.
Acabado através de elementos OOP primitivos. Provavelmente perdeu as habilidades de PF, mas aqui o OOP parecia muito mais simples e mais legível.
O código é muito simples e curto(descrição). Se você escrevê-lo em FP, seria interessante comparar.