Conversando sobre a OLP no salão - página 21
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
Militantes ignorantes - quão precisos e sucintos. Vou acrescentar ao meu vocabulário. :))
Não, a questão é diferente. Há uma banana que você tem que comer de acordo com a lógica do programa, mas você tem que comer a palma e a terra preta com o adubo junto com ela.
Bem, não.
Você não vê uma palmeira, terra preta, fertilizante ou um macaco. Está tudo encapsulado e você não tem acesso a ele.
É disso que eu estou falando! É apenas na abordagem funcional - você tem que arrastar tudo EXTREMELMENTE atrás de você para conseguir uma banana. Na abordagem do OOP, o compilador o arrastará para você. Você - faz a "banana" através de uma interface acordada, e você não sabe de onde ela veio. Você pode descobri-lo se tiver acesso adequado.
Esse é o objetivo do OOP - somente o que você precisa, neste caso a banana, deve estar disponível para você. Não há palmeira-fertilizante-pau-pau à sua disposição. Elas existem (caso contrário, de onde veio a banana), mas você não tem acesso a ela, e com toda sua vontade você não poderá cortar uma palmeira ou matar o próprio macaco que está arrancando sua banana.
O que é tormento para as pessoas normais é a alegria para os masoquistas. :)
Você poderia imaginar que a OLP é sua casa, com suas próprias regras. Há coisas que são comuns a todos. Estas são cadeiras de mesa, garfos, colheres, etc. Mas há coisas que não estão disponíveis nem mesmo para os moradores desta casa. Por exemplo, pertences pessoais, um cofre, etc.
O proprietário do cofre pode dar acesso ao cofre. Os estranhos não têm o direito de entrar nesta casa sem permissão.
Você pode usar uma classe para descrever esta casa, o que há nela com certas funções de cada um. E a própria casa é um objeto.
O OOP é como nossa vida. Parece uma pessoa e consiste de duas partes: a alma, que a descreve e controla, e o corpo físico, que é um objeto.
OOP é uma disciplina, não uma anarquia - quem quer que faça o que quer.
Afinal, o paradigma OOP só pode ser verdadeiramente compreendido por programadores reais que estão apaixonados por seu ofício.
Não necessariamente.
Renat na página anterior - observou com razão que "colocá-lo para fazer um projeto real" - ele fracassará. E ele rapidamente se convencerá de todas as vantagens do OOP, que mais do que compensam todas as desvantagens. Aposto que nenhum dos que criticam o OOP aqui participou da redação de um único projeto, mesmo um pequeno projeto complexo. O que explica sua opinião.
Como se "o carro requer muitos recursos gerais, e você não pode fugir deles, você tem que carregar aquela pilha de sucata o tempo todo, o que significa que é muito mais correto andar". E, de fato, é uma tolice ir para a próxima rua. Entretanto, se você tiver que ir para outra cidade - muito poucas pessoas falam seriamente sobre "caminhar".
E assim é aqui.
Não necessariamente.
Renat na página anterior - observou com razão que "colocá-lo para fazer um projeto real" - ele fracassará. E ele rapidamente se convencerá de todas as vantagens do OOP, que mais do que compensam todas as desvantagens. Aposto que nenhum dos que criticam o OOP aqui participou da redação de um único projeto, mesmo um pequeno projeto complexo. O que explica sua opinião.
Como se "o carro requer muitos recursos gerais, e você não pode fugir deles, você tem que carregar aquela pilha de sucata o tempo todo, o que significa que é muito mais correto andar". E, de fato, é uma tolice ir para a próxima rua. Entretanto, se você tiver que ir para outra cidade - muito poucas pessoas falam seriamente sobre "caminhar".
E assim é aqui.
Agora para micro-projetos de até cem mil linhas. Isto permite que você crie qualquer coisa, pois tem a chance de caber na cabeça de uma pessoa e manter a ilusão de controle. Quando você tenta aumentar a escala - dor, frustração e morte.
Dificilmente consigo imaginar até mesmo um projeto de linha 10K sem OOP. Provavelmente são muito poucos.
O tio é um teórico e tagarela, como a maioria no meio acadêmico. E não importa que ele seja professor (o título há muito tempo foi inflectido) e autor de livros.
Este lixo de frases tem andado por aí por muito tempo e ignora completamente o crescimento exponencial da complexidade dos produtos de software. O que era há 30-20-10 anos não é de forma alguma comparável à escala e complexidade dos projetos atuais. E eles ainda preferem brincar na caixa de areia, reduzindo-a a modelos.
Sente-o para fazer um produto real, que tem muitas exigências, inclusive de recursos, econômicas e competitivas. Ele se passará instantaneamente com seu raciocínio, falhando de todas as maneiras possíveis. É mais provável até mesmo que seja expulso por capitania infantil na fase de projeto da solução.
O mundo já tentou muitas balas de prata, mas todas elas provaram ser inúteis e há muito tempo foram eliminadas. Isso deixa um crescimento constante da complexidade, crescimento das bibliotecas (e há uma oop) e dos quadros (e há uma oop), o que permite pelo menos algum controle sobre a complexidade.
E não há como fugir da crescente complexidade. Haverá ainda mais complexidade, haverá mais desenvolvedores analfabetos incapazes de acompanhar as exigências de qualidade do conhecimento.
Haverá mais tentativas de criar idiomas ainda mais simples para atender ao nível de massa sempre decrescente dos programadores. Mais e mais empresas de software se encontrarão em desvantagem simplesmente por acreditarem na tecnologia errada e perderem a corrida competitiva. É que seus concorrentes utilizarão tecnologia mais pesada, mas eficaz em termos de resultados do produto.
Investir em empresas de software tem sido uma coisa mortal há muito tempo. As taxas de mortalidade e fracasso são espantosas, e a partir daqui as coisas vão piorar.
Por quê? Sim, porque é um negócio com grandes exigências econômicas, não tecnológicas. Cerca de 80% de uma empresa de software viva e permanente consiste em marketing e vendas. A tecnologia errada (e aqui a maioria das pessoas prioriza a suposta simplicidade) mata facilmente as vendas futuras. Porque sempre há concorrentes que tomaram um caminho mais difícil e obtiveram melhores resultados no final.
Agora sobre micro-projetos de até cem mil linhas. Isto permite que você crie qualquer coisa, pois tem a chance de caber na cabeça de uma pessoa e manter a ilusão de controle. Se você tentar aumentar a escala - dor, frustração e morte.
Conclusões:
Tudo isso é bom e bonito somente em palavras....
Para criar projetos grandes e interessantes usando OOP é necessário saber como fazê-lo.
1 - Aqueles que sabem como não vão aqui ao µl, o idioma é limitado a algumas plataformas, e são profissionais (já com projetos em outros idiomas) já em atividade...
2 - E aqueles que não sabem como, torcerão o OOP e outros como macacos e não darão à luz nada...
Sim, claro, há poucos fãs dos mercados financeiros, mas muito poucos para fazer algo sério e fazer uma vida para si mesmos... O principal interesse é...
O que quero dizer é que, Renat, o mt 5 terá em breve 10 anos, 10 anos não é brincadeira...
E não há treinamento adequado na programação OOP...
Qual é o tema sobre o qual eu escrevi? Sobre o OOP e o que se resumiu a isso? Para o lixo...
Minha pergunta a você Renat, como ou onde devem aparecer as pessoas que programam grandes projetos na mkl ???
como ou de onde devem vir as pessoas que programam grandes projetos em µl???
Nunca houve e nunca haverá grandes projetos em algotrading dentro de um único andar comercial, independentemente do idioma e da plataforma.
No máximo, há projetos semi-automatizados.
Mesmo um grande projeto como semi-automático em qualquer idioma? As unidades Scalper são as mais difíceis. Mas eles nunca tiveram um apelo em massa. E se não há massa, por que se preocupar com algo grande? É mais fácil construir algo para o mercado de um só joelho.