Regras de estrutura. Aprender a estruturar programas, explorar possibilidades, erros, soluções, etc. - página 3
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
Vá lá, eu não tinha nenhum modelo, depois comecei com o procedimento, depois mudei para modelo de objecto.
E em geral, por defeito a MQ dá-nos um modelo baseado em eventos. Inicialmente são-nos dados os acontecimentos pelos quais tudo acontece.
Estamos a falar de mq5?
portanto, estamos a falar da mesma coisa.
Do ramochamado "Erros, Insectos, Perguntas":
Um problema muito típico para o início da concepção: como organizar (estruturar) o tratamento de eventos num programa para que este (o programa) possa ser mais desenvolvido e, ao mesmo tempo, uma retrabalho mínimo do que já foi feito.
Quer discutir opções?
Em geral, esta é uma questão mais global e não se trata apenas de organizar um bom modelo de evento. Muito depende da própria língua. Infelizmente, os meios linguísticos da MQL5 situam-se ao nível dos anos 80 do século passado. As modernas normas de programação estão muito longe dos princípios originais da programação OOP. Hoje em dia a decomposição é preferível à herança, o polimorfismo é assegurado por ligações horizontais não hierárquicas a nível de interface, e a reutilização do código é assegurada por colecções ricas de bibliotecas padrão, design decomposto e inclusão transparente de construções de terceiros no projecto.
Existe alguma literatura, por exemplo?
Especificamente sobre este tópico:
Que língua considera como modelo a seguir (em termos de modernidade e usabilidade)?
Java/C#
E não é sequer o meu enviesamento (embora não esteja sem ele), mas o facto de estas linguagens serem o produto final de uma longa evolução na tecnologia de programação. Foram criados no nosso tempo, e baseavam-se na experiência dos seus predecessores.
Antes de escrever um grande projecto, é uma boa ideia estabelecer uma infra-estrutura claramente estabelecida para apoiar o projecto:
Existe alguma literatura, por exemplo?
É claro que há.
// Sobre literatura: vamos partilhar fontes literárias. Mas não esqueçamos que a comunicação ao vivo é por vezes muito (ordens de grandeza) mais eficaz para a aprendizagem do que os livros (mesmo os bons).
--
O livro foi muito útil em determinada altura (início dos anos 90):
B.Liskov, J.Gatag. "Utilização de abstracções e especificações no desenvolvimento de software".
Com ele, aprendi bem o ponto principal da programação orientada para objectos, que não é a possibilidade adicional de cortar o programa em "cubos" convenientes - isto é apenas uma conveniência adicional de acompanhamento. O ponto principal é a abstracção de dados.
Você pensa de forma orientada para o objecto, eu penso de forma funcional )
1. a abstracção processual (algoritmica) é uma característica da programação funcional. a entidade abstracta é o procedimento (função). Permite separar um pedido para executar uma acção ou cálculo da sua execução. O código de função é isolado num bloco separado (procedimento, função), este código é referido através da dissociação de parâmetros formais/actuais (esta é a essência e principal característica da abordagem processual). O programa é capaz de permanecer inalterado quando é necessário alterar a forma (algoritmo) de cálculo ou acção (por exemplo, escrever para um ficheiro).
Mas se um programa precisar de alterar qualquer estrutura de dados básicos (arrays globais, por exemplo), vai precisar de reescrever muitos procedimentos a trabalhar com estes dados. -- Esta é uma limitação básica do estilo de programação processual.
2) Abstracção de dados - encapsulamento das estruturas básicas de dados (juntamente com operações básicas sobre elas) em entidades separadas ("classes"), em conformidade com a regra básica: nunca se referir a elas (dados encapsulados) directamente, mas única e exclusivamente através das funções da mesma classe, especificamente criadas para elas ("interface"). Assim, a abstracção da forma de armazenamento de dados das formas de tratamento destes dados é conseguida.E existe uma oportunidade sem precedentes (na programação processual) - desenvolver um programa sem se preocupar antecipadamente com as formas de representação de dados. Uma vez que os dados são acedidos através de uma interface padrão imutável, é possível melhorar as formas de representação de dados em qualquer fase do desenvolvimento do projecto, e esta mudança não implica a necessidade de alterar outras partes do projecto. Na programação processual isto era impossível - a estrutura básica de dados determinou rigorosamente as formas do seu processamento.
Também me ensinaram a esboçar em papel, uma linguagem simplificada, antes de escrever o programa, mas nunca me habituei a ele.
Hoje em dia, nenhum programador normal desenha fluxogramas. É tudo um disparate teórico concebido para ensinar crianças em idade escolar, mas não para trabalhar em projectos reais.
Desenho no papel, é mais conveniente para mim, por vezes leva até 50 folhas até surgir uma estrutura clara. Pode, claro, utilizar editores especiais, mas cada um deles para mim é desconfortável (limitado), impossível de realizar um voo de fantasia, em suma, atrasam o trabalho.
E o que acontecerá à sua estrutura clara se no meio, ou ainda mais perto do fim do projecto, o cliente mudar subitamente:
Este é um bom teste para ver como o seu projecto está pronto e resiliente para mudar. Na prática, é sempre necessário lidar com mudanças nos requisitos iniciais. É portanto melhor abandonar o paradigma 'Providenciar para tudo' para o paradigma 'Tarefa - Solução'.