Programação OOP vs procedimento - página 14
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
Você pode me dar um exemplo dessas tarefas de tipo único, que são melhores não fazer sem o OOP?
Sem OOP você pode resolvê-lo, mas com OOP é mais rápido, eu lhe disse...
Por exemplo, um padrão pode conter de 0 a 100 padrões de castiçal, de 0 a 30 indicadores diferentes e de 1 a 5 sinais diferentes em cada um deles... Assim, temos 1 classe, e podemos definir com o construtor que a primeira instância conterá 23 desses padrões e 2 indicadores com 1 sinal cada... A segunda instância conterá 12 outros padrões e 8 outros indicadores. Então estabelecemos a condição de que ambas as instâncias devem dar um sinal para abrir não mais de 4 barras uma da outra ...
Tudo isso é feito em 5 segundos se os padrões sinalizarem e tudo mais for descrito na classe... E pode haver tantas combinações de tudo isso quanto você quiser, e mesmo sem um cliente, basta otimizar tudo isso automaticamente no otimizador e procurar por condições favoráveis de entrada... O otimizador pode aumentar o número de instâncias e propriedades de cada uma delas... bem, etc. )
Este não é o argumento principal.
Não há analogia de polimorfismo na programação de procedimentos.
É estranho que durante toda a minha prática, como fui um completo novato em programação e ainda sou, até certo ponto, nunca achei necessário o uso de polimorfismo... Esse deve ser meu destino.
(O inferno sabe por que...))
Sem OOP você pode resolvê-lo, mas com OOP é mais rápido, eu lhe disse...
Por exemplo, um padrão pode conter de 0 a 100 padrões de castiçal, de 0 a 30 indicadores diferentes e de 1 a 5 sinais diferentes em cada um deles... Assim, temos 1 classe, e podemos definir com o construtor que a primeira instância conterá 23 desses padrões e 2 indicadores com 1 sinal cada... A segunda instância conterá 12 outros padrões e 8 outros indicadores. Então estabelecemos a condição de que ambas as instâncias devem dar um sinal para abrir não mais de 4 barras uma da outra ...
Tudo isso é feito em 5 segundos se os padrões sinalizarem e tudo mais for descrito na classe... E pode haver tantas combinações de tudo isso quanto você quiser, e mesmo sem um cliente, basta otimizar tudo isso automaticamente no otimizador e procurar condições favoráveis de entrada... O otimizador pode aumentar o número de instâncias e propriedades de cada uma delas... etc. )
Todo este fracasso do Partido Republicano está em uma escala universal.
Afinal de contas, é preciso ter tanto talento para empurrar algo assim ao redor do mundo.
E nada impede os apologistas.
Se você aceitar apologistas locais. Bem debaixo de seus narizes está o manual de linguagem MQL. Vejamos as seções. Apenas três seções são dedicadas aos dados e todas as demais descrevem as AÇÕES: programa, operações de array, conversões de dados.....
Será que esta é a linguagem do µl que não está de acordo com as "idéias de vanguarda"?
Pegue um sistema de software muito maior: R.
Ela contém mais de 10.000 pacotes, cada um contendo funções - estas são ações, não objetos.
A meu ver, todos esses apologistas do OOP de origem local e mundial não entendem nada em programação, a saber: o valor (semântica) de qualquer dado é uma função, uma ação que processa esses dados. Eles escreveram int. O significado destes caracteres é determinado por um conjunto de comandos do processador, que sabe como realizar ACTION com esta variável.
A seguir, passemos às aulas.
Se tomarmos R, para o qual as aulas são parte do idioma.
Uma função insere um objeto de alguma classe - a saída é um objeto de normalmente outra classe. O significado dos campos de entrada-saída é determinado exclusivamente pela função que trata de tudo. E se a função não aceita uma determinada classe, esta classe não tem nenhuma utilidade para esta função. É por isso que a documentação para cada pacote é exatamente a mesma que a do µl: ações e funções são listadas. E as ligações entre funções em um pacote, ou com funções em outro pacote, são determinadas pelo nome da classe com a qual a função em particular trabalha.
Novamente. Em R, os objetos podem ter complexidade arbitrária e podem, na verdade, ser muito complexos. Mas o valor de cada campo de um objeto de uma determinada classe é inteiramente determinado pela função que gera esse objeto.
Isto é especialmente óbvio para aqueles que escreveram compiladores (e eu escrevi). Algumas seqüências de código são escritas. O que este código faz? Qual é o significado deste código? O significado do texto na linguagem fonte de qualquer linguagem de programação será determinado pelo código executável que o compilador criar, o qual será eventualmente percebido pelo processador. Um compilador de línguas encontrará o significado para as linhas escritas, mas outro não, ou seja, as linhas escritas não têm significado para esta outra língua.
Portanto: o significado de um objeto é sempre uma função, uma ação capaz de tomar dados de entrada como guia de ação, e gerar na saída uma determinada lista de campos, sendo o valor determinado unicamente por esta função.
Konov tentou explicar acima que temos que ir de ACTIONS. É necessário lidar com ações, e os objetos que conectam essas ações devem ser tratados posteriormente, quando as ações forem definidas. Mas a clareza e eficiência do código vem puramente de como conseguimos organizar bem toda a hierarquia das AÇÕES e sua interação.
Os defensores do OOP dizem: vamos criar objetos. Mas qual é o significado de campos de objeto se não definirmos ações nesses campos?
Como é implementado o padrão que contém os padrões? É uma função ou uma matriz ou algo mais? Como são escritos os padrões em si?
sim, geralmente são descritos, não é essa a questão...
Outro exemplo... uma classe é como uma biblioteca com livros, e uma cópia é um carrinho... Em um carrinho você pode colocar livros de sua escolha na biblioteca... ... e procurar algo mais lucrativo...) Biblioteca e 1 carrinho podem ser feitos sem OOP, e quando estamos falando de um grande número de carrinhos, é melhor fazê-lo com OOP...
Este é o único argumento a favor do OOP em desenvolvimento que eu aceito agora.
Você não deve aceitá-lo.
A última equipe em que trabalhei tinha cerca de 300 pessoas. A carga total de trabalho para todo o projeto do programa é de cerca de 1500 homens-anos. Organizar uma equipe desse tipo para trabalhar em conjunto não ajudará nenhum OOP. Para isso, houve outras abordagens, envolvendo a divisão de todo o problema em etapas e a regulamentação cuidadosa de tudo e de todos em cada etapa. Havia GOSTs que o descreviam. Na programação, foi o USSD (Sistema Unificado de Documentação de Programas). Em termos de intensidade de mão-de-obra, a codificação em si mesma absorveu cerca de 20% da entrada de mão-de-obra.
Não dê ouvidos aos defensores do OOP. Você está no caminho certo. Mesmo o fato de você não fundir duas variáveis em uma estrutura não mostra nenhum lucro
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 vamos falar do gerador, porque decidi não jurar durante 2 meses ))))
Camaradas desenvolvedores MQ, eu tenho muito respeito por vocês. Estou falando sério.
E compreendo as razões por trás da criação desses construtores. Também entendo porque é que todos esses construtores estão peidando no vácuo.
Sim, pode ser visto como uma espécie de exemplo para estudar a MQL5, mas de forma alguma como um ponto de partida para um verdadeiro robô comercial.
Você não deve aceitá-lo.
A última equipe em que trabalhei tinha cerca de 300 pessoas. A carga total de trabalho para todo o projeto do programa é de cerca de 1500 homens-anos. Organizar uma equipe desse tipo para trabalhar em conjunto não ajudará nenhum OOP. Para isso, houve outras abordagens, envolvendo a divisão de todo o problema em etapas e a regulamentação cuidadosa de tudo e de todos em cada etapa. Havia GOSTs que o descreviam. Na programação, foi o USSD (Sistema Unificado de Documentação de Programas). Em termos de entrada de mão-de-obra, a própria codificação levou cerca de 20% da entrada de mão-de-obra.
Não dê ouvidos aos defensores do OOP. Você está no caminho certo. Mesmo o fato de você não fundir duas variáveis em uma estrutura não dá muito lucro
San-Sanych, fui recentemente contatado por um progager chamado que até conseguiu vender algo no mercado.
Ele disse que eu tentei colar alguns programas e recebi um erro de compilação, então, para dizer, ele me enviou sua cola. Ele prometeu me pagar.
Eu dei uma olhada e estou doente, 59 erros de compilação.
Muitas variáveis globais como n,c,m.
Todos em conflito uns com os outros.
E o cara tem certeza de que só precisa de alguns ajustes e pode jogá-lo no mercado.
...
Segundo meu entendimento, todos esses apologistas do OOP de origem local e global não entendem nada em programação, a saber: o valor (semântica) de qualquer dado é uma função, uma ação, que processa esses dados. Eles escreveram int. O significado destes caracteres é determinado por um conjunto de comandos do processador, que sabe como executar ACTION nesta variável.
...
em memória
Você não deve aceitá-lo.
A última equipe em que trabalhei tinha cerca de 300 pessoas. A carga total de trabalho para todo o projeto do programa é de cerca de 1500 homens-anos. Organizar uma equipe desse tipo para trabalhar em conjunto não vai ajudar nenhum PON. Para isso, houve outras abordagens, envolvendo a divisão de todo o problema em etapas e a regulamentação cuidadosa de tudo e de todos em cada etapa. Havia GOSTs que o descreviam. Na programação, foi o USSD (Sistema Unificado de Documentação de Programas). Em termos de entrada de mão-de-obra, a codificação propriamente dita levou cerca de 20% da entrada de mão-de-obra.
Não dê ouvidos aos defensores do OOP. Você está no caminho certo. Mesmo o fato de você não fundir duas variáveis em uma estrutura não mostra nenhum lucro
Tais programas são agora escritos por uma pessoa em três dias.