Programação OOP vs procedimento - página 13
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
O que você quer dizer com a eficiência da solução?
Por eficiência da solução, quero dizer a qualidade da solução na qual o mecanismo - e o software é sem dúvida um mecanismo - funcionará da maneira mais estável. O mecanismo deve ser claro, coerente e produtivo. A funcionalidade do motor deve implementar todas as tarefas a ele atribuídas. O mecanismo não aceita nada supérfluo e, no desenvolvimento deste mecanismo, qualquer coisa supérflua deve ser cortada.
Caso contrário, ou não haverá desenvolvimento ou não haverá eficiência.
Esta é apenas a minha opinião e não estou impondo-a a ninguém.
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.
Eu não quero criar um coro aqui, mas eu me pergunto se os partidários do OOP podem submeter algum código resolvendo um problema, onde é claramente visível que esta solução é mais eficiente do que uma solução sem OOP?
Sou um mestre na resolução de problemas sem OOP e gostaria de lutar contra um mestre na resolução de problemas com OOP.
Vou tentar explicar-lhe, digamos que você é um fazedor e tem um cliente que sempre lhe dá algum trabalho a fazer. E depois de 5-6 ordens você percebe que todas as suas tarefas são semelhantes de alguma forma... E que você possa combiná-los em um padrão... E o cliente também gosta de combinar esses modelos entre si em grandes quantidades. E quando o cliente volta a pedir um trabalho difícil, basta criar o número necessário de instâncias (digamos, 10) deste modelo (classe) e a cada uma delas definir aquelas propriedades (no construtor) que ocorreram ao cliente... No final, a decisão de abrir uma ordem será simplesmente baseada em um loop que verá o resultado em cada uma das 10 instâncias, e é isso... Você pode rebitar tais pedidos em 5 minutos...
Mas você não poderá fazer uma instância sem o OOP e terá que refazer quase tudo, esperando que as mudanças não quebrem o que você tem... Como resultado, você vai gastar muito mais tempo...
Conclusão: um programador que conhece o OOP será capaz de resolver problemas (que são adequados para OOP) muito mais rápido e com menos erros...
Deixe-me tentar explicar, digamos que você é um artista e tem um cliente que está sempre lhe dando trabalho... E depois de cinco ou seis ordens, você percebe que todas as suas tarefas são, de certa forma, as mesmas... E que você possa combiná-los em um padrão... E o cliente também gosta de combinar esses modelos entre si em grandes quantidades. E quando o cliente volta a pedir um trabalho difícil, basta criar o número necessário de instâncias (digamos, 10) deste modelo (classe) e para cada uma delas definir aquelas propriedades (no construtor) que vieram à mente do cliente... No final, a decisão de abrir uma ordem será simplesmente baseada em um loop que resultará em cada uma das 10 instâncias, e é isso... Você pode rebitar tais pedidos em 5 minutos...
Mas você não poderá fazer uma instância sem o OOP e terá que refazer quase tudo, esperando que as mudanças não quebrem o que você tem... Como resultado, você vai gastar muito mais tempo...
Conclusão: Um programador proficiente em OOP será capaz de resolver problemas (que são adequados para OOP) muito mais rápido e com menos erros...
Talvez você esteja certo. Eu nunca fiz pedidos e não sei o que os clientes querem. O que você está descrevendo parece mais um trabalho de rotina, enquanto que é de desenvolvimento que estou falando aqui. Provavelmente para o trabalho de rotina (que também é feito por uma equipe), o OOP é insubstituível. Eu não tenho tal experiência e simplesmente não sei.
E você pode dar um exemplo específico dessas tarefas de tipo único, o que é melhor não fazer sem o OOP?
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.
Eu acredito firmemente que todo programador deve trabalhar em equipe, idealmente mais de 4 pessoas, apenas para entender que a eficiência e a generalidade do código não significa que o código seja bom.
Oh, trabalhar em equipe é uma canção à parte! E liderar uma equipe de programadores é uma canção em um grau igual ao número de participantes.
Contarei uma história em um sábado à noite. Sobre os tempos em que nossa firma costumava mergulhar e sair do ferro. Se isso se repetir, peço desculpas, posso já ter percorrido a história há algum tempo.
Meu chefe me convocou e perguntou: 'Você está muito ocupado no trabalho? Eu disse: "Nem por isso.
-O que você faz agora, afinal? O chefe nunca soube o que eu faço, porque fiz um horário pessoal, que incluía absenteísmo constante)).
Eu disse: "Sim, estou apenas escrevendo um pacote de teste para nosso equipamento. O chefe ficou tão satisfeito: "Ótimo, mesmo a tempo de experimentá-lo na Sibéria". Alexey, temos que sobrevoar, os caras estão presos lá, eles não conseguem descobrir. Eu adorava viagens de negócios, tinha total liberdade.
Eu voo para Krasnoyarsk, meus homens me encontram e olham para mim, todos parecem culpados. Fomos a um café, tomamos uma bebida, começamos a conversar. Eu lhe perguntei o que estava errado com você? O chefe estava perplexo, você estava em uma viagem de negócios há três meses e ficou preso em um ponto. Ele só tem tempo para lhe enviar dinheiro por transferência.
Bem, eles estão ao ar livre. Eles foram para uma aldeia siberiana, ficaram em uma casa de hospedagem e lá estavam duas irmãs jovens. Então, o amor girou e os amigos se envolveram, para que ninguém se sentisse ofendido.
Eu lhes disse que não te entregaria, eu sou da mesma maneira. Mas temos que manter o ritmo. Vamos apenas ajustar a coroa de flores inteira, faltando apenas alguns quilômetros, 500 quilômetros, depois eu te dou um bônus, torço o dinheiro do chefe e você e esses amigos comemoram o Ano Novo, certo?
Agora as mulheres ficarão indignadas, mas Lekha foi a primeira a concordar, dizendo que minha esposa deveria dar à luz, eu prefiro ficar aqui por um tempo! Todos eram casados e, por alguma razão, nenhum deles queria voltar para casa).
Por outro lado, entendi no meu instinto o quanto os rapazes podiam trabalhar duro quando as jovens e belas garotas siberianas estavam esperando por elas).
Isto não é um argumento de forma alguma.
Qualquer tarefa pode ser resolvida com ou sem o OOP. Sem OOP você também pode facilmente criar funções unificadas, que serão usadas muitas vezes e o programa inteiro não se quebrará por causa das mudanças que você introduzir nele. Há um pouco mais de código com o OOP. A legibilidade fica melhor devido ao uso do OOP? Não sei.
Eu tenho cada classe armazenada em um arquivo separado e cada função também em um arquivo separado. Apenas uma questão de hábito e conveniência.
Outro exemplo mais simples, que está na própria superfície... Gerador de EA no MetaEditor... Qualquer pessoa, mesmo que não saiba programar, pode empedrar um EA contendo um grande número de indicadores e condições em 10 segundos )))) E tudo isso é OOP ))
Não há nada a discutir.
Qualquer tarefa pode ser resolvida com ou sem o OOP. Você também pode criar facilmente funções unificadas sem OOP que serão usadas muitas vezes e o programa inteiro não se quebrará por causa das mudanças que você introduzir nele. Há um pouco mais de código com o OOP. A legibilidade fica melhor devido ao uso do OOP? Não sei.
Eu tenho cada classe armazenada em um arquivo separado e cada função também em um arquivo separado. Apenas uma questão de hábito e conveniência.
Aqui neste tópico havia um exemplo de um problema que pode ser resolvido sem OOP, mas de uma forma muito irracional.
Isto não é um argumento de forma alguma.
Qualquer tarefa pode ser resolvida com ou sem o OOP. Sem OOP você também pode facilmente criar funções unificadas, que serão usadas muitas vezes e o programa inteiro não se quebrará por causa das mudanças que você introduzir nele. Há um pouco mais de código com o OOP. A legibilidade fica melhor devido ao uso do OOP? Não sei.
Eu tenho cada classe armazenada em um arquivo separado e cada função também em um arquivo separado. Apenas uma questão de hábito e conveniência.
Posso dizer com certeza que não preciso de OOP no desenvolvimento pessoal, mas não tenho certeza sobre o trabalho em equipe em um grande projeto. O desenvolvimento e a comunicação do código criado por diferentes programadores nunca me ocorreu e não sei como eu o implementaria à minha maneira. Este é o único argumento a favor do OOP em desenvolvimento que aceito atualmente.
Este não é o argumento principal.
Não há equivalente de polimorfismo na programação de procedimentos.