Isto não é um problema com o OOP, mas com sua aplicação, e ainda mais com aqueles que o aplicam. Eles são os que sentem...
entusiasmo, até êxtase que com a ajuda do OOP você pode escrever incrivelmente
código incrivelmente complicado (e até mesmo competir nele :). Eles se sentem como uma elite especial.
Eles até inventaram seu próprio "grande livro" que eles leram e leram e leram, mas não podem
mas eles não conseguem lê-lo. É chamado de " Padrões de Design" - em linguagem humana
traduzido como "A Última Arte de Escrever Fuzzy, Muzzy e Código Confuso". Se, no entanto.
é uma coisa muito, muito legal, incrivelmente simplificadora e
simplifica e simplifica a vida.
Aí está, sempre suspeito)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23Você deve entender que tais artigos são provavelmente escritos por pessoas que não estão familiarizadas com FP e seus ganchos confusos, o que pode incluir 20 tabs....
Depois você começa a pensar em laconismo e conveniência do OOP, você pode declarar algumas das funcionalidades com antecedência e assim por diante..... Em essência, a semelhança de um com o outro. É que tais artigos são frequentemente escritos por pessoas que dominam apenas o código processual - e isto nem sequer é próximo do FP, portanto, se você não sabe quais são os ganchos e o uso vívido do mesmo, nenhum FP está fora de questão
Também muitas das "línguas moribundas" listadas no artigo suportam a funcionalidade total da PF e do OOP, por que deveriam morrer?! E algumas delas são as mais bem pagasno CISTrata-se mais de "esparguetetificação" no OOP, sem qualquer pensamento de "afogamento" no PF. Na minha opinião, o paradigma processual é realista e mais eficiente em termos de recursos do que o OOP.
apenas que o código em si é mais longo em oop? bem, sim, existe um construtor e em alguns casos o código é geralmente mais longo em oop.... tecnicamente, a implantação da FP deve ser mais eficiente para a geração de código de máquina.... mas o código não fica mais simples e é impossível fazer invólucros normais no que diz respeito à digitação...
hoje em dia, você pode encontrar frequentemente uma mistura de um e outro - maneiras de não interferir um com o outro
apenas que o código em si é mais longo em oop? bem, sim, existe um construtor e em alguns casos o código é geralmente mais longo em oop.... tecnicamente, a implantação da FP deve ser mais eficiente para a geração de código de máquina.... mas o código não fica mais simples e é impossível fazer invólucros normais no que diz respeito à digitação...
Hoje em dia, muitas vezes é possível ver uma mistura de um e de outro.
Sem OOP e FP tudo funciona mais fácil e rápido (sim, sem "belezas", painéis, etc.), mas às vezes é difícil de entender até mesmo seu próprio código)
Sem OOP e FP, tudo funciona mais fácil e rápido (sim, sem "belezas", painéis, etc.), mas às vezes é difícil de entender até mesmo seu próprio código).
Primeiro domine um ou outro, ou melhor ambos, e depois decida o que você prefere. E com uma abordagem como a de agora, você se transformará em Fedoseev que concorda com tudo o que você não entende (ou seja, quase tudo).
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.
Diga-me, como programador de procedimentos, como evitar a "spaghettização" no OOP
A receita é dada no artigo citado: esforçar-se para escrever funções determinísticas.
Como desmontar e faz sentido usar o "spaghetti" de outra pessoa?
Bom código, sim, mas não esparguete.
Afinal de contas, o OOP é principalmente para a legibilidade e programação em equipe, ou seja, para grandes projetos.
Certo.
Uma EA comercializando um símbolo a um gráfico do qual é anexado com o máximo controle de risco do saldo/conta, bem, não pode ser chamado de um grande projeto - assim, a programação de procedimentos é suficiente e mais lucrativa em termos de memória/velocidade.
Para viajar para a Austrália, é mais conveniente usar um avião (OOP), para viajar para uma cidade vizinha, um carro ou mesmo uma bicicleta é suficiente (PP). Você só tem que escolher o meio mais conveniente para atingir o objetivo.

- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
Aí está, sempre suspeito)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23