![MQL5 - Linguagem para estratégias de negociação inseridas no terminal do cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Não fique mistificado, ou eu lhe peço para entrar no clube, Peter.
A relevância do encapsulamento e do OOP já surge quando duas funções trabalham com uma variável comum.
Não fique mistificado, ou eu lhe peço para entrar no clube, Peter.
A relevância do encapsulamento e do OOP já surge quando duas funções trabalham com uma variável comum.
Não. Se você tem duas funções trabalhando com uma variável, declare-a global. Ou passá-lo de um para outro. Esta não é a razão para multiplicar as entidades.
E que tipo de OOP é este em três classes e duas estruturas? Por que precisamos de cadeias de herança tão curtas? A solução simples obtém uma sintaxe complicada e um conjunto de técnicas de sintaxe opcionais. Então, os seguidores começam a esmagar a funcionalidade para justificar a relevância do OOP. Do ponto de vista da solução, isto é errado.
A aplicação do OOP deve ser justificada por:
1. O desejo de aprender.
2. Para anexar sua solução a grandes programas ou bibliotecas.
3. Uma idéia global que leva ao crescimento e à complexidade do programa e à diversidade de seus dados.
Se este não for o caso e a solução não o exigir, não há necessidade de utilizá-lo.
Não. Se você tem duas funções trabalhando com a mesma variável, declare-a global. Ou passa de um para o outro. Esta não é a razão para a criação de novas entidades.
...
É exatamente isso! Para não transformar o código em uma confusão homogênea.
Comentários e um estilista ajudariam.
Sim. Também um caderno e uma maquiagem permanente na sua testa.
Esta é uma questão:
Se os cálculos dos indicadores forem implementados como uma classe, ela terá algum benefício? Ao escrever o Expert Advisor, ele permitirá evitar chamar o manípulo indicador e receber valores na última barra simplesmente conectando a biblioteca com esta classe.
O indicador pode ser escrito com referência a esta biblioteca.
O que você acha?
Esta é uma questão:
Se os cálculos dos indicadores forem implementados como uma classe, ela terá algum benefício? Ao escrever o Expert Advisor, ele permitirá evitar chamar o manípulo indicador e receber valores na última barra simplesmente conectando a biblioteca com esta classe.
O indicador pode ser escrito com referência a esta biblioteca.
O que você acha?
Incluir > Indicadores
Dê uma olhada, há exemplos de indicadores sobre as classes.
Incluir > Indicadores
Veja ali, há exemplos de indicadores sobre as classes.
Há exemplos, e daí? A mera existência destes exemplos não responde às perguntas feitas por @Alexey Viktorov.
Esta é uma questão:
Se os cálculos do indicador forem formatados como uma classe, isso seria de algum benefício?
Sim, nós o faremos. Pelo menos, em termos de conexão com o Expert Advisor. Este indicador está incluído no código como uma única linha. E nós não precisamos de nenhum iCustom.
É uma obrigação. Pelo menos em termos de conexão com a EA. Tal indicador é incluído no código em uma linha. E não há necessidade no iCustom.
Você pode dar um exemplo?