Programação OOP vs procedimento - página 12
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
Como posso usar o OOP se não consigo sequer me encaixar nas aulas? Eu simplesmente não preciso deles. Eu não preciso de estruturas. É uma divisão artificial, que não se justifica pelo autodesenvolvimento do meu programa. Exatamente - autodesenvolvimento. Não há outro nome para ele.
Portanto, neste processo, os próprios blocos de código são divididos por necessidade que nasce no processo de melhorá-los e acrescentar novas funções. Primeiro, são criadas funções, e depois são gradualmente combinadas em blocos maiores, que são polidos e atualizados com novas características. Com o tempo, esses blocos se desintegram e surgem novos blocos. Tudo acontece naturalmente. Eu apenas "giro" a nova funcionalidade para adquirir novas características, e depois a tritura para um estado de qualidade. Ao mesmo tempo, a estrutura do código está em constante mudança e transformação. Não mantenho nenhum esquema claro e tudo se desenvolve em direções imprevisíveis. De repente, neste processo, encontro oportunidades para um salto qualitativo. E eu dou este salto.
É assim que meu programa evolui. Ela se expande, depois encolhe, desmorona e emerge transformada. Há mudanças globais, saltos qualitativos, mas também há estados estáveis a longo prazo.
Neste processo, quaisquer regras desnecessárias e qualquer sintaxe de linguagem alienígena só irão retardar as coisas.
Como posso usar o OOP se não consigo sequer me encaixar nas aulas? Eu simplesmente não preciso deles. Eu não preciso de estruturas. É uma divisão artificial, que não se justifica pelo autodesenvolvimento do meu programa. Exatamente - autodesenvolvimento. Não há outra palavra para isso.
Portanto, neste processo, os próprios blocos de código são divididos por necessidade que nasce no processo de melhorá-los e acrescentar novas funções. Primeiro, são criadas funções, e depois são gradualmente combinadas em blocos maiores, que são polidos e atualizados com novas características. Com o tempo, esses blocos se desintegram e surgem novos blocos. Tudo acontece naturalmente. Eu apenas "giro" a nova funcionalidade para adquirir novas características, e depois a tritura para um estado de qualidade. Ao mesmo tempo, a estrutura do código está em constante mudança e transformação. Não mantenho nenhum esquema claro e tudo se desenvolve em direções imprevisíveis. De repente, neste processo, encontro oportunidades para um salto qualitativo. E eu dou este salto.
É assim que meu programa evolui. Ela se expande, depois encolhe, desmorona e emerge transformada. Há mudanças globais, saltos qualitativos, mas também há estados estáveis a longo prazo.
Neste processo, quaisquer regras e sintaxes desnecessárias com uma língua estrangeira só irão retardar as coisas.
No entanto, pode valer a pena gastar uma semana para resolver as estruturas. A afirmação "Eu não preciso de estruturas" parece realmente estúpida. A única conclusão é que você não sabe nada do que se trata.
Há tarefas que não podem ser resolvidas de maneira processual ideal.
Depende do que você quer dizer com "de forma ótima" )
No que me diz respeito, o OOP é apenas uma embalagem conveniente, não uma solução para qualquer problema. É por isso que o argumento está parado aqui.
Em geral, todos parecem concordar que qualquer tarefa será resolvida muito mais rapidamente e de forma mais compacta, utilizando uma abordagem estruturada-procedimento. E se gasta mais tempo para embrulhar em classes do que para codificar em si mesmo. Às vezes você se deixa levar, estraga um monte de aulas e depois pensa, por que se preocupar com tudo isso...
Mais uma coisa sobre "programação processual com indicadores de função" - por que deve ser colocada em uma categoria separada? Acho que os indicadores de função são apenas um estilo estrutural-procedural.
Depende do que você quer dizer com "maneira ideal" )
No que me diz respeito, o OOP é apenas uma embalagem conveniente, não uma solução para qualquer problema. É por isso que o argumento está parado aqui.
Em geral, todos parecem concordar que qualquer tarefa será resolvida muito mais rapidamente e de forma mais compacta, utilizando uma abordagem estruturada-procedimento. E se gasta mais tempo para embrulhar em classes do que para codificar em si mesmo. Às vezes você se deixa levar, estraga um monte de aulas e depois pensa, por que se preocupar com tudo isso...
Mais uma coisa sobre "programação processual com indicadores de função" - por que deve ser colocada em uma categoria separada? Acredito que os indicadores de função são apenas um estilo estrutural-procedural.
Opolimorfismo não é de forma alguma viável por meios processuais, exceto por indicações de função. O OOP é definitivamente polimorfismo, enquanto na programação de procedimentos não há necessariamente indicações de funções.
Não se deve embrulhar tudo nas aulas.
Não deveríamos passar pelo menos uma semana lidando com as estruturas? A afirmação "Eu não preciso de estruturas" parece realmente estúpida. A única conclusão é que você não sabe nada do que se trata.
A estrutura é uma coisa auto-explicativa. Ela combina um conjunto nomeado de variáveis de diferentes tipos. O principal tipo no meu programa é int. O dobro é usado apenas em alguns poucos lugares. cordão apenas em um bloco em particular.
Por que eu preciso de estruturas no contexto do OOP?
Eu tenho uma estrutura que pertence ao núcleo. Ou seja, a estrutura do próprio núcleo dentro dele. É tudo o que eu preciso.
A estrutura é auto-explicativa. Ela combina um conjunto nomeado de variáveis de diferentes tipos. O principal tipo no meu programa é int. Eu só uso o dobro em poucos lugares. cordão apenas em um bloco em particular.
Por que eu preciso de estruturas no contexto do OOP?
Eu tenho uma estrutura que pertence ao núcleo. Ou seja, a estrutura do próprio núcleo dentro dele. É tudo o que eu preciso.
Você deve ter escrito um programa para si mesmo por três anos.
Você pode, mas com diferentes eficiências de operação. O apoio não é o problema aqui, é muito relativo.
Há tarefas que não podem ser resolvidas de forma otimizada.
Sou um apoiador do OOP, mas na verdade, o processador não sabe nada sobre a existência do OOP, ele pode executar o código da máquina, só isso. Na aurora do computador, eles escreveram programas desta maneira, diretamente em código de máquina.
É por isso que havia tantas mulheres programadoras. Porque os homens se embebedariam e ficariam loucos por causa desse trabalho).
Afinal de contas, concordo - o que conta é a eficiência da solução.
A sobrecarga de sintaxe e complexidade das regras nunca contribuiu para manter a eficiência das soluções. Foi a simplicidade e a brevidade expressas na concisão, universalidade e legibilidade dos blocos de código que ajudaram.
E o que se entende por soluções eficientes?
Minhas regras de programação são: menos código, menos regras, menos sintaxe...
Eu não sou fã do OOP.
Mas em termos de manutenção, escalabilidade e facilidade de uso por terceiros, o que o TC (Peter, não Karputov) está empurrando é apenas a idade da pedra.
Tenho uma forte opinião de que todo programador deveria trabalhar em equipe, idealmente mais de 4 pessoas, apenas para entender que eficiência e universalidade do código não significa que este código seja bom.
Sou um defensor do OOP, mas na verdade, o processador não sabe nada sobre a existência do OOP, ele pode executar o código da máquina, só isso. Nos primeiros tempos do computador, era assim que se escreviam os programas, diretamente em código de máquina.
É por isso que havia tantas mulheres programadoras. Porque os homens bebiam muito e se tornaram loucos por causa deste trabalho).
O que é isso? Até agora, uma conclusão é que no início você tinha que escrever muitos programas em código de máquina))