Programação OOP vs procedimento - página 22
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 fato de todos os sistemas modernos utilizarem o OOP não é prova de superioridade ? Você simplesmente não está pronto para entender, faz perguntas simples e não pode aceitar uma resposta complexa... e acha que não há resposta... Bem, isso não está certo...
A mentalidade muda, sim, e a princípio parece que para quê? Mas quando o projeto se torna um monte de milhares de linhas de código, você começa a colher os benefícios)) e entender por que e para que tudo isso foi).
Se um projeto é difícil e caro de manter e atualizar, e caro e caro de estender, e outro é rápido e fácil, o primeiro morrerá - é uma seleção natural.
Há muitos milhares de linhas de código em meu programa também. A falta de entidades desnecessárias é uma salvação para mim. Eu não teria sido capaz de desenvolvê-lo de outra forma. É a prática mais pura.
Mas chega disso. Estou deixando esta linha.
1. O fato de todos os sistemas modernos usarem OOP não é prova de superioridade?
2. Você simplesmente não está pronto para entender, faz perguntas simples e não consegue entender a resposta complexa... e acha que não há resposta... Isso não está certo.
Quando sua mentalidade muda, sim, e no início você se pergunta para quê. Mas quando o projeto se torna um monte de milhares de linhas de código, você começa a colher os benefícios)) e entender por que e para que tudo isso foi).
Se um projeto é difícil e caro de manter e atualizar, e outro é rápido e fácil de implementar, o primeiro morrerá - esta é uma seleção natural.
1) Todos aqui são tão legais, que isso não será uma prova para eles, mas pelo contrário, a prova de que todos eles são tão legais de si mesmos, e todos ao redor são tristes otários - eles se apaixonaram pelo OOP.
2. Muito anedótico, mas eles não se dão conta disso.
Similar a este tópico )) Há muito tempo atrás eu assinei a revista Popular Mechanics, havia uma página de humor
Um dia, Leo estava em pé de guerra. Então, ele está andando, todo descarado. Ele encontra uma raposa. Raposa, rápido, quem é o rei dos animais?
- Leva, é claro que você é!
Satisfeito, ele prosseguiu.
Ele encontrou a lebre, o mesmo resultado.
E o elefante estava quente, apenas acenou com a tromba das moscas e o leão voou para longe.
E você sabe o que ele disse ao elefante que partiu, sentado nos arbustos?
- E não fique bravo se não souber as respostas).
Sobre o ouriço:
"O ouriço está de pé na clareira, posando, flexionando seu bíceps: - Sou forte, sou corajoso, sou ágil, sou forte, sou corajoso, sou ágil...
Um urso passa - pontapeia-o uma vez, o ouriço voa atrás da árvore, levanta-se e sacode a si mesmo:
- Sou forte, corajoso, ágil... Mas eu sou fácil...
Mas já chega disso. Deixo este tópico.
O fato de você não confiar nos outros e querer entender por si mesmo é até bom, outros podem estar errados, algumas coisas são mais fáceis de entender por si mesmo
1. todos aqui são tão legais que para eles não será uma prova, mas uma confirmação de que todos eles são tão legais de si mesmos, sabem como, e todos ao redor de otários tristes - caíram na OLP.
2) Muito anedótico, mas eles não se dão conta disso.
))) É engraçado como as pessoas que não entendem muito vendem consultores especialistas de mercado por $10K ou sinais com 2k assinantes e ganham muito dinheiro )
Este não é o argumento principal.
Não há analogia de polimorfismo na programação de procedimentos.
Como isso não existe, se você mesmo mencionou anteriormente várias páginas de indicações de funções? Este é o próprio análogo do polimorfismo, e com possibilidades muito mais amplas, porque você pode mudá-lo dinamicamente.
Parece que você perdeu a conversa :-) os moderadores se agarraram a temas em chamas ... mas aqui é OOP vs.
A propósito, 99% dos @Peter Konow's usam OOP, mas ele não está ciente disso :-) OOP não é necessariamente "classe & modelo".
e vice-versa também...a presença de objetos e classes em um programa não é indicativa do OOP
Como não, quando você mesmo mencionou as indicações de função algumas páginas antes? Este é o próprio análogo do polimorfismo, e com possibilidades muito mais amplas, pois pode ser mudado dinamicamente.
Isso foi ontem, enquanto eu tinha uma opinião melhor sobre a oposição. Recentemente surgiram apontadores para as funções na MQL, mas hoje se constatou que para todos os argumentadores eles não existem de todo. Acontece que eles não sabem sobre o que estão discutindo. Tenho certeza de que eles simplesmente perderam as palavras"polimorfismo" e "ponteiros" em seus olhos e ouvidos. Eles têm apenas um argumento - "você não citou nenhuma prova", mesmo que eles vejam 1000 provas aqui.
Você também pode mudar dinamicamente os indicadores para as classes, a única coisa mais simples com as funções é que você não precisa criá-las primeiro.
Por eficácia 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 atribuídas a ele. O mecanismo não aceita o supérfluo e, no desenvolvimento deste mecanismo, o supérfluo deve ser cortado.
Somente no seu caso este "desnecessário" é o controle de tipo e outras coisas fundamentais que se destinam a proteger o código de erros de programação acidentais. É por isso que seu código se torna muito pouco confiável. Não há estabilidade alguma. Mesmo que você o tenha depurado e limpo agora, mas outras modificações causarão erros difíceis de encontrar que são muito difíceis de limpar.
Não há dúvida de que o OOP contém muitas ferramentas adicionais que um desenvolvedor pode utilizar. Entretanto, deve-se entender o preço a ser pago pelo uso dessas ferramentas. Nomeadamente, você deve mergulhar no paradigma OOP e na estruturação do código correspondente a ele. Usando todo o conjunto de ferramentas OOP e criando muitos objetos. O principal preço está na complicação acentuada do código. Entretanto, a prática mostra que do ponto de vista da eficiência dos mecanismos criados eles devem ser simples e a presença de quaisquer entidades neles deve ser absolutamente comprovada pelo aumento da eficiência e nada mais.
Somente no seu caso, este "extra" é um controle de tipo e outras coisas fundamentais para manter seu código a salvo de erros acidentais de programação. É por isso que seu código se torna muito pouco confiável. Não há estabilidade alguma. Mesmo que você o tenha depurado e limpo agora, mas outras modificações causarão erros difíceis de encontrar que são muito difíceis de limpar.