Programação OOP vs procedimento - página 40

 
Andrei:

Exatamente, de uma pessoa específica. Por que um programador que não está sofrendo de esquizofrenia esconderia de si mesmo o acesso a alguma parte de seu próprio código que ele está depurando? Você não prefere amarrar suas próprias mãos? :)

Bem, como eu disse, tente trabalhar com o arquivo de estrutura que Peter deu acima. "Busque" os dados que você precisa dali, e depois coloque-os de volta no lugar certo.

E compare com a obtenção dos dados necessários a partir de uma interface "aparada" que lhe dá um pouquinho da mesma estrutura. Com uma interface, simplesmente não há como obter algo mais, ou escrever algo "errado".

Não, é compreensível que se você é um titã de memória com capacidade de esquecimento atrofiado - então você tem sorte, e não precisa de OOP. Mas nem todos têm tanta sorte.

Assim, a SanSanych se oferece para substituir o OOP por documentação - em princípio, é também uma opção, de fato, está muito mais próxima das estruturas propostas por Peter. Mas com Peter toda a documentação está "em mente" e com SanSanych - em papel (ou em mídia eletrônica).

 
Andrei:

Pergunto-me o que é este "horror".

A propósito, Renat Fatkhullin, seria realmente interessante olhar para exemplos...

 
George Merts:

Não, é compreensível que se você é um titã de memorização com uma capacidade atrofiada de esquecer, então você tem sorte, e não precisa de OOP. Mas nem todos têm tanta sorte.

Assim, SanSanych sugere a substituição do OOP por documentação, que é também uma opção, em princípio, muito mais próxima das estruturas propostas por Peter. É que a documentação de Peter está "em mente" e a de SanSanych está em papel (ou em mídia eletrônica).

O significado de uma variável deve ser conhecido em qualquer caso, mas não é necessário lembrar - você pode escrever um comentário se o contexto não estiver claro. Parece óbvio.

Com OOP você tem que lembrar e documentar muito mais, ou seja, o que é criado e destruído quando e em que momento, através de que interfaces flui em que momento e outras absolutamente inúteis para a confusão do resultado final do mouse - só disso qualquer pessoa sadia pode ficar louca e quebrar seu cérebro.

 

A propósito, para todos os oponentes do OOP - seria bom lembrar os tempos em que os programas eram escritos em linguagem de assembleia.

E em particular - trabalhar com arquivos usando BIOS e DOS.

Na minha opinião, a diferença entre as abordagens de procedimento e OOP é exatamente a mesma que na manipulação de discos com ferramentas BIOS e DOS.

Tanto BIOS como DOS têm todas as funções necessárias para trabalhar com o disco.

Entretanto, criar um arquivo com as características da BIOS e escrever "Olá, mundo!" é um grande problema até mesmo para as unidades FAT. Eu costumava fazer isso em um desafio, e não era fácil para mim. No DOS é fácil de fazer com apenas uma função.

Posso imaginar como seria difícil criar um arquivo desse tipo para o sistema NTFS usando BIOS...

 
Andrei:

Leia com atenção, é sobre a classe, não sobre o construtor da classe.

Além disso, você novamente sugere fazer o trabalho de um macaco - plantar um campo em um terreno, se pudermos ter acesso aos parâmetros sem fazer QUALQUER coisa no caso de variáveis externas ou passá-las diretamente, sem dores de cabeça desnecessárias com construtores-destrutores e todos os vazamentos de memória que isso acarreta.


Sim, eu preciso entrar e você está me mostrando a porta aqui. Você provavelmente não sabe o que é um construtor de classes.

Apenas parâmetros gerais - eles já são visíveis dentro da classe, mas usá-los não é bom, OOP é bom para a capacidade de escapar do espaço comum.

E diretamente como? Se não através de uma porta, então através de uma parede? Através do construtor é como passar diretamente. Você pode passar parâmetros imediatamente ao criar um objeto, mesmo sem novo. Então você é preguiçoso demais para descrever os parâmetros que a classe deve aceitar? Você não é preguiçoso demais para escrever funções e declarar variáveis?

Você obviamente não entendeu nada do que eu escrevi)).

 

Dmitry Fedoseev:

Você não é preguiçoso demais para escrever funções e declarar variáveis?

Você tem que escrever funções e declarar variáveis em todos os lugares e também no OOP. Somente com o OOP haverá muito mais confusão com ele, e isto é, se você prever antecipadamente tudo profeticamente, qual será a estrutura de dados no final do projeto, para que você não tenha que reescrevê-lo uma centena de vezes. Parece óbvio.

 
Andrei:

Você tem que escrever funções e declarar variáveis em todos os lugares e também no OOP. Somente no OOP será muito mais exigente, e isto se você prever com antecedência tudo profeticamente, qual estrutura de dados estará lá no final do projeto, para que você não tenha que reescrevê-lo uma centena de vezes. Parece óbvio.


É mais um incômodo, mas há muitos casos em que vale a pena. Em geral, não é fatal.

 
Dmitry Fedoseev:

É mais um incômodo, mas há muitos casos em que vale a pena. Não é fatal em geral.

Quando vale a pena o trabalho - quando você paga por hora, porque quanto mais agitação, mais lucrativo é. :)
 
Dmitry Fedoseev:

Há quanto tempo você está trabalhando nesta sua biblioteca?

Dois anos de trabalho ininterrupto.

O núcleo GUI (a propósito, há também um núcleo proto-kernel contendo elementos protótipos. Ocupa 2 megabytes. Ela consiste em tabelas como a que citei) e contém milhares de variáveis. Você acha que se eu não tivesse usado o núcleo como centro e espalhado variáveis sobre classes e estruturas e estabelecido comunicação entre elas através de várias restrições de acesso, eu teria lidado com minha tarefa? - Nunca por minha conta. Eu teria multiplicado o número de entidades em meu programa. As ligações dentro do código entre funções e classes se tornariam tão complexas que eu simplesmente não seria capaz de continuar trabalhando por conta própria. A eficiência de todo o mecanismo teria caído a pique.

Eu teria chegado ao meu limite muito mais cedo e teria parado.

Muitas vezes me perguntei "o que eu teria conseguido se tivesse usado o OOP?" e cada vez, com base na prática diária, percebi que não teria sido capaz de ir tão longe sozinho.

Além disso, meu pensamento está estruturado como está e, portanto, não tenho necessidade de OOP a este respeito.

 
Renat Fatkhullin:

Por uma questão de alegria - R está escrito em um modo absolutamente nojento "tudo em uma lata de lixo, sem diferenciação de acesso". Uma abordagem old-school de vinte anos atrás, sem áreas de visibilidade, proteção ou multisessão. Escrevo como se eu fosse o único. Sim, o projeto nasceu sob uma pessoa por desenvolvedores não-profissionais. Ela deve ser reescrita do zero. Pelo menos uma vez.

Tive a idéia de fazer uma interface normal em R a partir da MQL5, mas depois de me aprofundar nela, decidi imediatamente não integrá-la. O sistema é categoricamente incapaz de proteger os dados e as sessões.

Até que um programador trabalhe em equipes normais de desenvolvimento com requisitos rigorosos (batendo as mãos por pelo menos alguns anos) ele não se tornará um desenvolvedor em um sentido normal. Agarramos nossas cabeças 90% do tempo quando olhamos para trabalhos de teste quando consideramos candidatos. Um horror total em toda a indústria de desenvolvimento.

Portanto, mais uma vez - os oponentes do OOP estão exibindo algum tipo de bufonaria aqui.

Desculpe novamente.


Renat, por favor, não fique nervoso. Eu mesmo não sou um apoiador do R. Você é um excelente gerente e programador, não leve a sério a gritaria do fórum.

Desejo a você, ao Rashid e à sua equipe boa saúde e sucesso criativo!

Razão: