Programação OOP vs procedimento - página 26
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
Não há muito em que pensar.
O OOP é um mecanismo que nos permite passar muitas verificações e aprovações para o compilador. No entanto, temos que gastar algum esforço extra para usá-lo.
Mas se não precisamos de todos esses cheques e encaixes, não faz sentido usar o OOP.
Por exemplo, eu estaria desconfiado de trabalhar com uma matriz multidimensional de kernel gráfico - porque tem muitas entidades desnecessárias que não são necessárias no momento. Eles distraem e provocam erros difíceis de calcular. Eu o substituiria por um conjunto de objetos, aos quais eu teria acesso com interfaces compactas simples. Ao obter uma interface - não preciso me lembrar de nada - a própria interface me limita e me impede de, digamos, acessar o campo ou objeto errado. No caso de uma matriz de kernel gráfica, tal manipulação é muito possível.
Isto é, no caso em que um bloco recebe uma interface, o próprio compilador "corta" todas as entidades desnecessárias e evita que o usuário cometa um erro. Mas no caso de uma matriz de kernel gráfica, o usuário tem muitas informações desnecessárias onde ele pode facilmente cometer um erro.
Em minha experiência, sei que estou muito melhor quando o próprio compilador está cuidando de mim para ter certeza de que não vou onde não devo ir no bloco atual. E com uma matriz gráfica do núcleo - tenho que lembrar disso. O "menos" do meu sistema é uma extensão do "mais". Se de repente eu precisar de algo em um bloco que vá além da tarefa atual, com uma matriz de kernel gráfica é fácil - basta pegar os dados necessários e trabalhar com eles. Mas com as interfaces OOP, você terá que solicitar os dados necessários em uma interface adicional, ou (o que é muito mais desagradável) modificar a interface existente.
Não há muito em que pensar.
O OOP é um mecanismo que nos permite passar muitas verificações e aprovações para o compilador. No entanto, temos que gastar algum esforço extra para usá-lo.
Mas se não precisamos de todos esses cheques e ajustes - não há sentido no OOP.
Mas por que simplificá-lo tanto? E quanto à clareza e legibilidade? E simplicidade na detecção e correção de erros? E a portabilidade? E facilidade de atualização? etc., etc. ....
Bem, então o tema deve soar diferente. Algo como: "Um novo conjunto de ferramentas na programação" ou "Um novo paradigma de programação"...
Se é verdade que você criou algo mais legal do que o OOP, então você vai autografar o seu quando se tornar famoso?
Sem problemas! Nenhuma despesa poupada para um autógrafo para seus amigos. ))))
Você está brincando, mas na minha imaginação, tenho uma perspectiva tão grande sobre esta abordagem que é um verdadeiro aborrecimento. Parece que com o tempo serei capaz de iniciar o mecanismo de auto-aperfeiçoamento do sistema. Se eu fizer um kernel lógico e o fizer gerar diferentes mecanismos de forma aleatória. Depois basta fazer uma seleção e selecionar as corretas. Depois moa-os um pouco... graças ao miolo, coisas incríveis podem ser feitas.
Por que simplificar tanto as coisas? E a clareza e legibilidade? E facilidade de detecção e correção de erros? E quanto à portabilidade? E facilidade de atualização? etc., etc. ....
belo anúncio em banner :-) "comprar nossos elefantes".
todas estas teses são igualmente aplicáveis a OOP e não-OOP e FP e em todos os outros lugares
Não há muito em que pensar.
O OOP é um mecanismo que nos permite passar muitas verificações e aprovações para o compilador. No entanto, temos que gastar algum esforço extra para usá-lo.
Mas se não precisamos de todos esses cheques e encaixes, não faz sentido usar o OOP.
Digamos, eu estaria desconfiado de trabalhar com uma matriz multidimensional de kernel gráfico - porque ele tem muitas entidades desnecessárias que não são necessárias no momento. Eles distraem e provocam erros difíceis de calcular. Eu o substituiria por um conjunto de objetos, aos quais eu teria acesso com interfaces compactas simples. Ao obter uma interface - não preciso me lembrar de nada - a própria interface me limita e me impede de, digamos, acessar o campo ou objeto errado. No caso de uma matriz de kernel gráfica, tal manipulação é muito possível.
Isto é, no caso em que um bloco recebe uma interface, o próprio compilador "corta" todas as entidades desnecessárias e evita que o usuário cometa um erro. Mas no caso de uma matriz de kernel gráfica, o usuário tem muitas informações desnecessárias onde ele pode facilmente cometer um erro.
Pela minha experiência, fico muito melhor quando o próprio compilador vai acompanhar as coisas que eu não deveria mexer no bloco atual. E com uma matriz gráfica do núcleo - tenho que lembrar disso. O "menos" do meu sistema é uma extensão do "mais". Se de repente eu precisar de algo em um bloco que vá além da tarefa atual, com uma matriz de kernel gráfica é fácil - basta pegar os dados necessários e trabalhar com eles. Mas com as interfaces OOP, você terá que solicitar os dados necessários em uma interface adicional, ou (o que é muito mais desagradável) modificar a interface existente.
Você está errado ao pensar que há algo desnecessário no núcleo. E é muito fácil lembrar de suas entidades, pois elas estão vestidas com palavras humanas através de definições. Tudo é coletado ali, mas este conteúdo tem uma ordem clara e imutável. As propriedades dos objetos, janelas e elementos são diretamente acessíveis em qualquer ponto do programa. E que maravilhas você pode fazer com o grão em loops...
Você está completamente errado ao pensar que há algo a mais no núcleo. E lembrar de suas entidades é muito fácil, pois elas são revestidas de palavras humanas através de definições. Tudo é coletado ali, mas este conteúdo tem uma ordem clara e imutável. As propriedades dos objetos, janelas e elementos são diretamente acessíveis em qualquer ponto do programa. E que maravilhas você pode fazer graças ao grão em loops.
Eu não disse que "o núcleo é redundante", eu disse "desnecessário no momento". Se estou trabalhando com uma linha gráfica - não deveria ser capaz de acessar as propriedades da janela.
Apenas o fato de todas essas propriedades serem diretamente acessíveis em qualquer parte do programa é a principal desvantagem de sua abordagem. Em qualquer lugar do programa, somente os elementos que são necessários neste momento devem ser acessíveis. Todo o resto deveria estar indisponível. Isto - permite que você evite automaticamente muitos erros.
Todas as "maravilhas que você pode fazer devido à acessibilidade de todo o núcleo" são, em minha opinião, uma fonte potencial de erros difíceis de encontrar e problemas de compreensão do código. Deve-se tentar evitar todos esses truques.
Esta abordagem me lembra de tarefas muito bobas quando indicações, incrementos e referências são escritos em uma linha em uma confusão que talvez seja correta do ponto de vista linguístico, mas não legível de forma alguma. Citei minha própria função acima, que também parece absolutamente louca, mas achei que a compactação é mais importante neste caso.
Bem, por que simplificá-lo tanto? E clareza e legibilidade? E facilidade na detecção e correção de erros? E a portabilidade? E facilidade de atualização? etc., etc. ....
Fantástico!
1. Antes da oop, todos nós estávamos construindo tudo a partir de componentes sob medida com ferramentas excepcionalmente complexas
2. Antes do OOP, os programas eram uma compota excepcionalmente bem misturada
3. Antes do OOP NÃO tínhamos ouvido falar sobre localização de dados e códigos e isso tornava nossa manutenção extremamente dolorosa.
4. A proteção de dados entre diferentes partes de um mesmo programa foi um pesadelo!
5. Antes do OOP, nunca ninguém estendia os sistemas.
Isto é um fracasso completo.
Sento-me e penso que talvez este mesmo OOP tenha surgido de mim porque apliquei tudo isso no final dos anos 70 e muitas outras coisas relacionadas com a cultura da programação.
Eu não disse "há algo desnecessário no núcleo", eu disse "desnecessário no momento". Se eu estou trabalhando com uma linha gráfica - não deveria ser capaz de acessar as propriedades da janela.
Apenas o fato de todas essas propriedades serem diretamente acessíveis em qualquer parte do programa é a principal desvantagem de sua abordagem. Em qualquer lugar do programa, somente os elementos que são necessários neste momento devem ser acessíveis. Todo o resto deveria estar indisponível. Isto - permite que você evite automaticamente muitos erros.
Todas as "maravilhas que podem ser realizadas devido à acessibilidade de todo o núcleo" são, em minha opinião, uma fonte potencial de erros difíceis de encontrar e problemas de compreensão do código. Deve-se tentar evitar todos esses truques.
Esta abordagem me lembra das tarefas mais bobas quando as indicações, incrementos e referências são escritas em uma linha em uma confusão que pode ser correta do ponto de vista do idioma, mas é absolutamente ilegível. Citei minha própria função acima, que também parece absolutamente louca, mas achei que a compactação é mais importante neste caso.
Você está raciocinando sobre o núcleo com base em noções teóricas momentâneas baseadas em sua experiência, que nada tem a ver com a tecnologia de que você está falando. Daí alguns problemas de acesso, lembrando entidades...
Estou raciocinando por experiência prática com esta tecnologia, e estou dizendo que não existem tais problemas de acesso ou limitação. Sinceramente, não sei de que problemas de acesso você está falando. Não há tais problemas e nunca houve nenhum.
Por favor, explique a que questões de acesso você está se referindo.
O que o faz pensar que o acesso deve ser restrito se isso causaria erros? Isto é algo novo para mim.
O acesso direto a uma matriz global em um código de procedimento pode causar erros difíceis de encontrar por si só?
Você está falando do núcleo baseado em noções teóricas imediatas baseadas em sua experiência, que não tem nada a ver com a tecnologia de que você está falando. Daí alguns problemas de acesso, lembrando entidades...
Estou raciocinando por experiência prática com esta tecnologia, e estou dizendo que não há tais problemas de acesso ou limitação. Sinceramente, não sei de que problemas de acesso você está falando. Não existem e nunca existiram tais dificuldades.
O que você quer dizer com "sem problemas" quando diz que "tudo pode ser acessado de qualquer lugar"?
Esse é o principal problema! Não deveria ser acessível!
O objetivo é transferir a tarefa de controle de acesso para o compilador. Tudo está aberto, e o programador controla o acesso.
Não houve complicações porque você se lembra de tudo. Você já está acostumado. Bem, eventualmente você verá que sua memória está começando a falhar, e então você apreciará a capacidade do compilador de controlar o acesso. Eu não me lembro. E suspeito que a maioria das pessoas também esquece periodicamente como algo escrito meses atrás funciona. É nestas circunstâncias que o controle de acesso se torna um trunfo.
Digamos, se você estiver dentro do bloco que é responsável por fazer pedidos - você só tem a capacidade de fazer pedidos. E você não tem a capacidade de desenhar um gráfico. Se você está em um bloco que é responsável pelo desenho de uma carta, não pode fazer um pedido a partir daí. Isto simplifica muito o trabalho. E quando na função de desenho gráfico você de repente vê um pedido para fazer um pedido, você terá que lembrar por muito tempo porque fez isso. Seria bom se houvesse um comentário detalhado explicando porque esta decisão foi tomada... Mas é melhor quando as encomendas são colocadas em um único bloco dedicado.
Como pode haver "nenhum problema" se você diz "tudo é acessível de qualquer lugar"?
Esse é o principal problema! Não deve ser acessível !
O objetivo é apenas transferir a tarefa de controle de acesso para o compilador. E tudo está aberto, e o programador controla o acesso.
Não houve complicações porque você se lembra de tudo. Você já está acostumado. Bem, eventualmente você verá que sua memória está começando a falhar, e então você apreciará a capacidade do compilador de controlar o acesso. Eu não me lembro. E suspeito que a maioria das pessoas também esquece periodicamente como algo escrito meses atrás funciona. É nestas circunstâncias que a delimitação de acesso se torna uma bênção.
Digamos, se você estiver dentro do bloco que é responsável por fazer pedidos - você só tem a capacidade de fazer pedidos. E você não tem a capacidade de desenhar um gráfico. Se você está em um bloco que é responsável pelo desenho de uma carta, não pode fazer um pedido a partir daí. Isto simplifica muito o trabalho. E quando na função de desenho gráfico você de repente vê um pedido para fazer um pedido, você terá que lembrar por muito tempo porque fez isso. Seria bom se houvesse um comentário detalhado explicando porque esta decisão foi tomada... Mas é melhor quando as encomendas são colocadas em um único bloco dedicado.