Que código OOP pode fazer que o código de procedimento não pode?
O OOP é projetado para funcionar e pensar como os seres da natureza , vamos imaginar se quisermos desenvolver um jogo de guerra onde temos veículos com muitos tipos , soldados com muitas habilidades e armas com muitas especificações.
Desenvolver este tipo de jogo sem OOP será uma dor para o desenvolvedor para manter o controle de todos estes tipos de objetos e para gerenciar bem as estruturas de dados e a memória, e também para simular as características OOP como herança será difícil ( embora possa ser feito ), OOP tornou mais fácil pensar e desenvolver também esier para escrever ler e depurar o código .
Algumas vezes ter OOP mais do que o necessário tornará a compreensão e leitura do código pouco amigável (meu ponto de vista pessoal) que eu não gosto
Na verdade, não creio que possa existir uma tarefa que não possa ser refatorada do código de procedimento para o OOP ou vice-versa. A diferença está na capacidade de manutenção e legibilidade do código. Por exemplo, no código de procedimento você pode fazer referência a dados globais e/ou locais (variáveis). Além destes, o OOP acrescenta mais um escopo - variáveis internas do objeto (estado). É muito fácil e natural usá-las no OOP, e a implementação de procedimentos da mesma lógica exigiria algum tipo de solução com códigos e estruturas de dados adicionais. Em outras palavras, o OOP é apenas uma maneira mais curta e agradável de codificar.
Como você quer construir uma solução para funções virtuais sobrecarregadas, incluindo a árvore da herança - que é a parte mais importante do OOP? Você parece falar de estruturas, não de OOP.
OOP é projetado para funcionar e pensar como os seres da natureza , vamos imaginar se queremos desenvolver um jogo de guerra onde temos veículos com muitos tipos , soldados com muitas habilidades e armas com muitas especificações.
Desenvolver este tipo de jogo sem OOP será uma dor para o desenvolvedor para manter o controle de todos estes tipos de objetos e para gerenciar bem as estruturas de dados e a memória, e também para simular as características OOP como herança será difícil ( embora possa ser feito ), OOP tornou mais fácil pensar e desenvolver também esier para escrever ler e depurar o código .
Algumas vezes ter OOP mais do que o necessário tornará a compreensão e leitura do código pouco amigável (meu ponto de vista pessoal) que eu não gosto
Fórum sobre negociação, sistemas de negociação automatizados e teste de estratégias de negociação
Que código OOP pode fazer que o código de procedimento não pode?
Alain Verleyen, 2016.05.22 14:03
Estou abrindo este tópico na esperança de coletar informações úteis sobre as vantagens da programação orientada a objetos versus programação procedural.
Além disso, este tópico é independente da linguagem, pois mql4 e mql5 oferecem a mesma linguagem OOP (exceto algumas novas características avançadas ainda não disponíveis em mql4 no momento).
Eu não quero uma "guerra" entre partidários e oponentes do OOP, portanto, este tópico será moderado de perto, não perca seu tempo e o meu, por favor.
Por favor, forneça também exemplos e códigos para ilustrar seu ponto de vista, não uma teoria elevada ou conceitos abstratos.
EDIT: embora este tópico seja independente da linguagem, ainda estamos falando de comércio e mql4/mql5, portanto, nada de "jogos de guerra" ou "maçãs e laranjas" exemplos, por favor.
Sou um grande fã do OOP - não posso sequer imaginar que voltaria ao MQL de procedimento. É mais fácil tornar os programas mais complexos. De qualquer forma... o problema com o MQL é que um novo usuário tem dificuldade para começar aqui.
- os métodos de eventos incorporados não são OO. Você tem que se ligar a eles, o que exige a declaração dos objetos de escuta no nível da raiz. Um dos princípios básicos do OOP está comprometido com este projeto.
- faltam pacotes de códigos de 'sistema' com padrões comuns. Isso impede a criação de pacotes compatíveis entre usuários, e um codificador OOP sério precisa de muito tempo para criar seus pacotes privados. Prefixos de nomes de classe não suportados (nomes de pacotes) são apenas um problema menor - quando não se pode reutilizar o código externo de qualquer forma.
Portanto, eu não recomendaria começar a aprender o OOP direito no MQL. O codificador precisa saber o que ele precisa para que ele funcione.
"se...então...senão..." declaração deve fazer o trabalho.
Uh, vamos lá ;) Nem por isso ;) Se algo nativo poderia fazer o trabalho de alguma forma estranho, então suas indicações, mas há restrições na MQL. Se assim não fosse ... o código se tornaria absurdo. E se você aceitar o código absurdo como uma resposta à questão deste tópico, então ele se tornará obsoleto ;) Você concorda que o absurdo é uma boa fronteira? Vamos, diga sim, só uma vez e só para o meu ego ;)
Desculpe, mas não vou dizer sim...um código ou está alcançando seu objetivo ou não, se estiver funcionando de acordo com as especificações, não há nada de absurdo.
A questão é "o que o OOP pode fazer que o procedimento não pode fazer" ? Stanislav estava dizendo que a OOP pode fazer o mesmo que o procedimento, mas de uma forma "mais curta e mais agradável". Eu tendo a concordar (exceto sobre a idéia mais curta, mas isso não é tão importante).
Programar GUIs foi o que mais fiz durante todo o meu tempo como programador. Não é possível codificar uma GUI completa que precisa se comunicar em várias direções até então. Você precisaria de tantas declarações que o código se tornaria ilegível e, no final, também muito lento, o que significaria: Meta não alcançada, pois não quero ser forçado a beber uma xícara de café após cada clique até ver o resultado.
Devido à circunstância de uma CPU não saber nada sobre o OOP, você pode - é claro - codificar tudo sem usar apenas apontadores e arrays complexos. Mas isso é um absurdo. Eu também poderia contratar 10000 pessoas que desenham meu conteúdo de tela no filme em tempo real e o teletransportam sequencialmente por um projetor de luz na parede. Isto também está atingindo o objetivo?
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
Estou abrindo este tópico na esperança de coletar informações úteis sobre as vantagens da programação orientada a objetos versus programação procedural.
Além disso, este tópico é independente da linguagem, pois mql4 e mql5 oferecem a mesma linguagem OOP (exceto algumas novas características avançadas ainda não disponíveis em mql4 no momento).
Eu não quero uma "guerra" entre partidários e oponentes do OOP, portanto, este tópico será moderado de perto, não perca seu tempo e o meu, por favor.
Por favor, forneça também exemplos e códigos para ilustrar seu ponto de vista, não uma teoria elevada ou conceitos abstratos.
EDIT: embora este tópico seja independente da linguagem, ainda estamos falando de comércio e mql4/mql5, portanto, nada de "jogos de guerra" ou "maçãs e laranjas" exemplos, por favor.