Perguntas OOP (Object Oriented Programming) - página 2
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 sempre, eu queria aprender, mas é certo que há quem não tem mais nada a dizer a não ser ser ser esperto...
Escrevi um exemplo simples para desmontá-lo, não sei como escrever de forma mais competente com o OOP ... É apenas um exemplo, se você souber escrever um código similar corretamente e OOP então, por favor, escreva, para que eu e outros possam aprender ...
O OOP começa com a busca de um objeto. Se não houver nenhum objeto, não há OOP.
Normalmente, um objeto são alguns recursos, dados.
Você só tem que escrever e observar como os outros escrevem. Então você vai descobrir por si mesmo. Você também poderia ler livros didáticos. Há muitos deles na Internet.
O OOP começa com a busca de um objeto. Se não houver nenhum objeto, não há OOP.
Normalmente, um objeto são alguns recursos, dados.
Você só tem que escrever e observar como os outros escrevem. Então você vai descobrir por si mesmo. Você também poderia ler livros didáticos. Há muitos deles na Internet.
Recomendar alguns livros didáticos, por favor ... O mais fácil e mais útil em sua opinião ...
Recomende alguns tutoriais, por favor ... O mais fácil e mais útil em sua opinião ...
Grady Buch. "Análise e Projeto Orientado a Objetos". Com exemplos de aplicações C++".
Ire Paul (às vezes se escreve Ira Paul) "Programação orientada a objetos em C++".
1) Não relacionado ao OOP, mas o manipulador de erros de operação comercial(OrderSend(), OrderDelete(), OrderModify() ) deve ser adicionado...
Para torná-lo relevante para o OOP - torná-lo como um método de classe virtual (para substituí-lo em classes descendentes, adicionando o processamento de outros códigos).
2) Todos os métodos de classe que nas classes descendentes podem funcionar de forma diferente do que agora - torná-losvirtuais.
O primeiro candidato é o de ordem aberta().
A desvantagem é que nos métodos virtuais, não se pode alterar o número e o tipo de parâmetros.
No lado positivo, os "velhos" Buy, Sel, BuyStop etc. poderão chamar os "novos" (alterados na classe infantil) de openorders()
3) Vamos ter nomes mais bonitos de uma só vez. Ordens Abertas em vez de ordens abertas, por exemplo.
4) Se a terminologia é para chamar algo, então você deve usar terminologia semelhante.
Se vender = VENDER, então você o chama de VENDER ou VENDER (ou seja, SellStop em vez de SelStop)
5) Você deve remover todas as constantes (500, etc.) da classe.
Deixar que sejam retirados de variáveis ou definidos como parâmetros de métodos.
Agora você se lembra de cerca de 500 embutidos em ordens abertas(), mas mais tarde você esquecerá ou escreverá um monte de corujas usando estas classes e será difícil mudar qualquer coisa.
A coisa mais difícil de consertar são os erros arquitetônicos.
E é o esqueleto que você está criando agora (se não for apenas um exercício).
6) Não coloque tudo em uma só classe.
Faça uma classe clOrder e cole SetSL, CloseOrder, GetSL, GetProfit, SetTP, GetTP , etc. com ele.
E na classe clTrade , adicionar uma matriz/lista de pedidos, um símbolo e propriedades do símbolo(TICKETSIZE, POINT, TICKETVALUE, MINLOT, MAXLOT, STOPSTEP, LOTSTEP, LOTSIZE , etc.).
Se você anexar Ask e Bid (como propriedades de um símbolo), não se esqueça de atualizá-los em OnTick().
Para RefreshRates(), faça uma ligação para que após a atualização de МТ as variáveis Ask e Bid Properties sejam chamadas (eu também verifiquei o status dos pedidos, quem abriu e quem fechou. Os fechados são retirados da lista de pedidos).
Você pode adicionar horário (primeiro de tudo, fazer uma classe) e parada de retaguarda (também fazer uma classe separada).
PS: Fiz tudo no fim de semana (fiz biblioteca para ofícios), mas desta vez decidi sem classes (apenas estruturas, conjuntos de estruturas e funções que funcionam com tudo isso).
Há também um horário para cada dia (já que os Alpes sobre ouro têm uma pausa todos os dias das 0:00 às 13:00). Nos últimos 2 minutos de negociação, o verificador de horários fecha todas as negociações e cancela todas as ordens.
E na última hora de negociação - fecha os negócios perdidos, cancela as ordens e os trilhões lucrativos. Eu também fiz uma parada de trilha. Um tipo, mas se adapta a símbolos diferentes devido a parâmetros diferentes.
O esquema é o seguinte - símbolos (com seus próprios campos), ordens (com seus próprios campos), horários (com seus próprios campos) e um Expert Advisor com seus próprios campos (magik, etc.) referindo-se a um símbolo e tendo uma lista de ordens e uma lista de horários.
O topo da hierarquia é a lista de Conselheiros (símbolo + combinação estratégica deve ser única).
Recomende alguns tutoriais por favor ... O mais simples e útil em sua opinião ...
Exemplos escritos usando OOP estão agora aparecendo no CodeBase. Da VOLDEMAR, por exemplo ))))
Na verdade, seu https://www.mql5.com/ru/code/11159 foi o que me inspirou a reescrever minha biblioteca comercial de estruturas.
Decidi esperar com as aulas - não vejo a utilidade de usá-las na MQL .
Ou é padrão apenas na MQL5, e é apenas retomado a partir daí no novo MetaEditor?
Exemplos escritos usando OOP estão agora aparecendo no CodeBase. Da VOLDEMAR, por exemplo ))))
Na verdade, seu https://www.mql5.com/ru/code/11159 foi o que me inspirou a reescrever minha biblioteca comercial de estruturas.
Decidi esperar com as aulas - não vejo a utilidade de usá-las na MQL até agora.
Sim, eu escrevi isto, mas além de transferir funções para uma classe, ainda não entendi mais nada,
Sim, eu escrevi isso, mas além de transferir funções para uma classe, eu ainda não entendi mais nada,
3(+1) Princípios do OOP:
1) Encapsulamento. Isto é, armazenar variáveis, pseudo-variáveis (chamadas "propriedades do objeto" ou apenas "propriedades") no próprio objeto. Ou seja, se uma classe é declarada corretamente, seus dados não podem ser alterados a partir do exterior.
Somente utilizando as funções da própria classe (referidas como "métodos de classe" ou simplesmente "métodos"). Necessário não apenas para atribuir um valor a uma variável, mas para realizar alguma ação em conexão com a mudança desses campos.
E esta é a principal (na minha opinião) utilidade de introduzir o OOP no MQL, em vez de portar funções (as funções da minha biblioteca comercial recebem o índice da EA como um dos parâmetros e trabalham com a EA selecionada, incluindo seu conjunto de ordens).
Ninguém pode entrar nos dados de uma classe criada por você (se não houver código fonte) e depois reclamar que seu código tem erros.
2) Herança. Quando uma classe ancestral é criada, ela herda todos os campos e métodos da classe ancestral (há um tipo privado para os campos e métodos que não podem ser vistos nas classes ancestrais, mas estamos omitindo isto por enquanto).
E aqui na fase de projeto do objeto você precisa pensar claramente através da arquitetura - como a classe será usada, que campos ela conterá, como eles devem ser visíveis nas classes descendentes, etc.
É usado em sistemas poderosos e bibliotecas de classe, para tarefas que eu pessoalmente não vejo em tarefas comerciais. Mas talvez alguém venha a precisar. Você pode fazer classes de descendentes com diferentes paradas para descer, por exemplo.
É por isso que - sem constantes métodos internos, tudo deve ser definido externamente através de métodos apropriados (geralmente começam com .Set) ou diretamente como parâmetros de métodos. Isso é o que eu quero dizer sobre seus 500.
3) Polimorfismo. O que escrevi acima - quando uma remodelada em uma função de classe descendente abre ordens() chamará livremente as antigas funções Buy().
Um exemplo de polimorfismo é o cálculo da área de uma figura geométrica para diferentes formas.
É calculado de uma forma para um círculo, de outra forma para um quadrado. Mas em qualquer caso - chamando Figura.GetSquare() obteremos a área de uma determinada forma herdada de uma classe base (se não esquecêssemos de declarar Square() ).
Mais uma vez é necessária alguma qualificação para criar a arquitetura da classe base. Por exemplo, esquecer de declarar Square() como virtual tornará impossível chamar Square de forma genérica (você terá que verificar o tipo de classe antes de cada chamada e chamar sua implementação de Square).
Algumas pessoas recomendam tornar virtuais todos os métodos, exceto os construtores (eu tenho a mesma visão se você não consegue ver o horizonte em que esta classe pode crescer quando você a cria). O principal é que os desestruturadores também devem ser virtuais.
Atualização:
================
4) Abstração (como solicitado pelos camaradas, embora quando estudei o OOP (nos anos 90) não foi considerado um princípio (pois de fato - apenas derivado dos três primeiros), e no artigo (ver link abaixo) está escrito sobre ele, mas não está no título do artigo, há apenas 3).
Na aplicação prática, está criando uma classe base "vazia" (onde os métodos são declarados, mas não fazem nada). Em alguns idiomas, um método pode ser marcado de forma tão abstrata, o que significa que em uma classe descendente ele deve necessariamente ser sobreposto (ou seja, um método que faz algo é adicionado).
===================
PS: você pode ler brevemente, sem entrar em muitos detalhes, aquiPPS: Não quero ofender ninguém, mas quando pedi no Trabalho para escrever uma biblioteca comercial, apenas 1 pessoa respondeu que a tem e a usa.
5 MQL-programadores (no Skype) disseram que não tinham idéia do que deveria estar nele e copiaram - colar as funções necessárias de uma de suas corujas para outra. Eles até mesmo colam RefreshRates() entre fragmentos de código que não mudam nada e não podem ser executados mais do que alguns milissegundos. E o código subseqüente não depende de pedidos e licitações alterados e (talvez) tipos de pedidos.
Portanto, para programadores MQL que nunca trabalharam com OOP em outras linguagens de programação antes, o OOP em MQL não será útil. No máximo, ele esconderá dados de mudanças externas (o que também não é ruim).
3) Os 3 princípios do OOP:
1) Encapsulamento. Isto é, armazenamento de variáveis, pseudo-variáveis (referidas como "propriedades do objeto" ou simplesmente "propriedades") no próprio objeto. Isto é, se uma classe é declarada corretamente, seus dados não podem
2) Herança. Quando uma classe ancestral é criada, ela herda todos os campos e métodos da classe ancestral (há um tipo privado para campos e métodos que não podem ser vistos nas classes ancestrais, mas nós omitimos aqui por enquanto).
3) Polimorfismo. O que escrevi acima - quando remodelado em uma função de classe descendente, as ordens abertas() chamarão com segurança funções antigas de Buy( ), etc.
Um exemplo de polimorfismo é o cálculo da área de uma figura geométrica para várias formas.
É calculado de uma forma para um círculo e de outra forma para um quadrado. Mas em qualquer caso, chamando Figura.GetSquare() obteremos a área de uma determinada forma herdada da classe base (a menos que nos esqueçamos de declarar Square() ).
Onde está o quarto?! Onde está o abstrato! Esquecido imerecidamente :-(
Acrescente.