Se a questão é para meu exemplo - pelo menos você esconde a implementação (você a esconde até de si mesmo) - ou seja, você escreve apenas a lógica dos cálculos, é conveniente, é legível, permite que você evite erros lógicos
SZZY: Com relação à negociação - escrevi e ainda faço experimentos com grades de ordens, onde escrevo a lógica de colocar ordens como A + B - C, onde A, B, e C - ou seja, ordens com parâmetros pré-definidos, muito úteis para algoritmos genéticos- tópico interessante
As embaladoras são uma solução boa e lógica. Quando se adequa ao propósito. E eu acho que as embalagens são uma inovação na linguagem processual. Exatamente no sentido de novidade e utilidade.
Quanto à negociação - escrevi e ainda realizo experimentos com grades de ordens onde escrevo a lógica de colocação de ordens como A + B - C , onde A, B e C são ordens com parâmetros predefinidos - é muito útil para algoritmos genéticos- é um tópico interessante
A, B, e Ccom parâmetros predefinidos- como um fenótipo para algoritmos genéticos?
O encapsulamento dá liberdade de nomes. E se este problema for resolvido pela lógica do nome. Isto, claro, é caro. então a pitão pode ser escrita em funções. mas não será uma solução comercializável. MAS ISSO É POSSÍVEL.
Em python, qualquer função é um objeto, assim como uma variável)
em python, qualquer função, como uma variável, é um objeto)
Tudo o que você pode fazer é usar referências para resolver tudo, desde que os nomes não se sobreponham. Uma função é obviamente um objeto, mas seu resultado é unificado internamente, e somente em global e público você pode olhar para dentro. i like python logic))))
a empresa OOP é Java. Em nosso domínio, Du* *opy é representado (aspergido para não ficar atolado). Se você quer beleza de objetos - tente entender e lembrar com sobriedade seu API, felizmente o tema é conhecido :-)
Mas é tudo uma merda...
Para aumentar sua habilidade de programação, você pode querer aprender algo que lhe dê uma reviravolta mental. Por exemplo, há o Rebol/Red ( https://www.red-lang.org/)- uma coisa incrível, não está claro, mas é legal.
ou um clássico, Smalltalk(https://pharo.org/). Você pode até mesmo utilizá-lo na produção.
E tudo isso "vamos escrever A+B em estilos diferentes" é brincadeira de criança, honestamente.
E então todas as perguntas sobre quem é mais frio, OOP ou FP desaparecerão por si só.
In the past months, many new features were added to Red/System, the low-level dialect embedded in Red. Here is a sum up if you missed them. Subroutines During the work on the low-level parts of the new Red lexer, the need arised for intra-function factorization abilities to keep the lexer code as DRY as possible. Subroutines were introduced to...
Onde o OOP é mais conveniente, eu uso OOP, onde preciso economizar memória e tempo, e código para mim mesmo, eu fico com o procedimento. Acabei de encontrar um artigo, eu queria ouvir as opiniões, onde/quilo é melhor). Resultado - ouvi muitas coisas diferentes em meu endereço, não sobre programação) Tudo está como de costume.
Portanto, ninguém lhe dirá nada de novo. Use com o que você se sente confortável, só isso.
Para minimizar erros, existe toda uma área chamada programação probatória (verificação formal em particular).
Como medida parcial para melhorar a qualidade do código, você pode sugerir seguir qualquer estilo de codificação comum (por exemplo, estilo de código google), utilizando asserções, restrições (const, override, especificadores de acesso) que de fato não afetam a execução, mas causam erros de compilação se usadas incorretamente, familiarizar-se com as abordagens em design em geral
O fato é que, além das áreas críticas de programação, é geralmente mais importante tirar a versão de produção rapidamente do que obter a qualidade do código, o que é ruim, mas verdadeiro.
Para login e uso do site MQL5.com, você deve ativar o uso de cookies.
Ative esta opção no seu navegador, caso contrário você não poderá fazer login.
Você entrou na conta. A autenticação de dois fatores foi desativada. Configure-a novamente e escaneie um novo código QR ou continue com a autenticação de dois fatores desativada.
Se a questão é para meu exemplo - pelo menos você esconde a implementação (você a esconde até de si mesmo) - ou seja, você escreve apenas a lógica dos cálculos, é conveniente, é legível, permite que você evite erros lógicos
SZZY: Com relação à negociação - escrevi e ainda faço experimentos com grades de ordens, onde escrevo a lógica de colocar ordens como A + B - C, onde A, B, e C - ou seja, ordens com parâmetros pré-definidos, muito úteis para algoritmos genéticos- tópico interessante
As embaladoras são uma solução boa e lógica. Quando se adequa ao propósito. E eu acho que as embalagens são uma inovação na linguagem processual. Exatamente no sentido de novidade e utilidade.
Quanto à negociação - escrevi e ainda realizo experimentos com grades de ordens onde escrevo a lógica de colocação de ordens como A + B - C , onde A, B e C são ordens com parâmetros predefinidos - é muito útil para algoritmos genéticos- é um tópico interessante
A, B, e C com parâmetros predefinidos- como um fenótipo para algoritmos genéticos?
O encapsulamento dá liberdade de nomes. E se este problema for resolvido pela lógica do nome. Isto, claro, é caro. então a pitão pode ser escrita em funções. mas não será uma solução comercializável. MAS ISSO É POSSÍVEL.
Em python, qualquer função é um objeto, assim como uma variável)
A propósito, um exemplo de OOP contínuo é Python. Ali, ao contrário, ninguém sabe que existe outra coisa além do OOP.
há fechamentos e você pode escrever sem OOP, pelo menos no antigo, o que você quiser.
em python, qualquer função, como uma variável, é um objeto)
Tudo o que você pode fazer é usar referências para resolver tudo, desde que os nomes não se sobreponham. Uma função é obviamente um objeto, mas seu resultado é unificado internamente, e somente em global e público você pode olhar para dentro. i like python logic))))
há fechamentos e é possível escrever sem oop, pelo menos no antigo, o que se quiser
bem você pode, mas ainda assim o bloco mínimo de construção é um objeto
Já não o vejo há algum tempo...
Será que ele realmente ficou com um nome de tela diferente?
Não, não é Peter, é um estilo de escrita diferente.
a empresa OOP é Java. Em nosso domínio, Du* *opy é representado (aspergido para não ficar atolado). Se você quer beleza de objetos - tente entender e lembrar com sobriedade seu API, felizmente o tema é conhecido :-)
Mas é tudo uma merda...
Para aumentar sua habilidade de programação, você pode querer aprender algo que lhe dê uma reviravolta mental. Por exemplo, há o Rebol/Red ( https://www.red-lang.org/)- uma coisa incrível, não está claro, mas é legal.
ou um clássico, Smalltalk(https://pharo.org/). Você pode até mesmo utilizá-lo na produção.
E tudo isso "vamos escrever A+B em estilos diferentes" é brincadeira de criança, honestamente.
E então todas as perguntas sobre quem é mais frio, OOP ou FP desaparecerão por si só.
bem você pode, mas ainda assim o bloco mínimo de construção é a instalação
o objeto foi um avanço.
Onde o OOP é mais conveniente, eu uso OOP, onde preciso economizar memória e tempo, e código para mim mesmo, eu fico com o procedimento. Acabei de encontrar um artigo, eu queria ouvir as opiniões, onde/quilo é melhor). Resultado - ouvi muitas coisas diferentes em meu endereço, não sobre programação) Tudo está como de costume.
Portanto, ninguém lhe dirá nada de novo. Use com o que você se sente confortável, só isso.
Para minimizar erros, existe toda uma área chamada programação probatória (verificação formal em particular).
Como medida parcial para melhorar a qualidade do código, você pode sugerir seguir qualquer estilo de codificação comum (por exemplo, estilo de código google), utilizando asserções, restrições (const, override, especificadores de acesso) que de fato não afetam a execução, mas causam erros de compilação se usadas incorretamente, familiarizar-se com as abordagens em design em geral
O fato é que, além das áreas críticas de programação, é geralmente mais importante tirar a versão de produção rapidamente do que obter a qualidade do código, o que é ruim, mas verdadeiro.