Conversando sobre a OLP no salão - página 7
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
ZS: a propósito, eu não vi um único desejo de cobertura de qualquer tópico em todo o fio, como de costume, o rancor habitual.
A julgar pela escolha do exemplo inicial, existem dúvidas razoáveis sobre a qualidade da cobertura
Podemos ser mais específicos sobre quem eles são e o que não aprenderam? Os moderadores não aprenderam a limpar ou outra coisa qualquer )
ZS: a propósito, em toda a linha não houve um único desejo de cobrir qualquer tópico, como sempre, o rancor habitual. Então decidi gravar vídeos no YouTube do zero sobre como o OOP funciona, pelo menos ele será de alguma utilidade. De qualquer forma, dentro de algum tempo o ramo acabará na sucursal.
Deixe-me ser mais preciso: eles ainda não aprenderam a usar o OOP.
Alexey, eu acho que você está bem ciente de si mesmo que não pode simplesmente aprender o OOP. Há um conhecimento formal do OOP: herança, encapsulamento, polimorfismo - todos esses mantras são freqüentemente repetidos, mas há mais danos do que benefícios de alguém que os memoriza e os aplica violenta e inapropriadamente, como uma classe de Especialistas para herdar de um módulo MM (olá aos desenvolvedores SB:).
Quanto à MQL - é uma linguagem muito fraca em termos de OOP: o controle de tipo está completamente ausente (pelo menos eles fizeram uma conversão segura), a reflexão está em sua infância e muito limitada, não há nenhuma interface. A pergunta que surge: que tipo de OOP pode ser ensinado na MQL? O que dizer, se os próprios desenvolvedores estão fazendo tal confusão na Biblioteca Padrão que às vezes é apenas assustador.
Para ser mais preciso: não aprendemos o OOP.
Alexey, eu acho que você está bem ciente do fato de que não pode simplesmente aprender o OOP. Há um conhecimento formal do OOP: herança, encapsulamento, polimorfismo - todos esses mantras são freqüentemente repetidos, mas há mais danos do que benefícios de alguém que os memoriza e os aplica violenta e inapropriadamente, como uma classe de Especialistas para herdar de um módulo MM (oi para desenvolvedores SB:).
Quanto à MQL - é uma linguagem muito fraca em termos de OOP: o controle de tipo está completamente ausente (pelo menos eles fizeram uma conversão segura), a reflexão está em sua infância e muito limitada, não há nenhuma interface. A pergunta que surge: que tipo de OOP pode ser ensinado na MQL? O que dizer, se os próprios desenvolvedores moldam tal corcunda na biblioteca padrão que às vezes é apenas assustador.
Sim, é fraco, mas projetos de média severidade ainda podem ser feitos. SB tem sido feito por diferentes pessoas com diferentes níveis de treinamento. E falta o essencial, eu ainda uso seu cdicionário, e é a coisa devida ao mastro.
Então, e agora, deitar-se e morrer? )) Afinal de contas, você pode entrar na dll.
Você pode aprender OOP, eu acho. Eu mesmo o aprendi. E outros também o fizeram.
E você ainda pode aprender OOP, eu acho. Eu mesmo o aprendi. E outros também.
Portanto, você tem que aprender com os exemplos certos. Mas não há nenhum em SB. Tomemos como exemplo o CObject - ele não fornece controle de tipo, não fornece trabalho em nível de interface com objetos, mas contém métodos sem sentido como Save() e Load() que nunca são redefinidos na prática. Os indicadores m_prev e m_next são usados em uma única classe CList, mas estão presentes como lastro para todas as suas classes descendentes. O mais útil é o método Comparer(). Na verdade, ela é substituída na maioria das vezes. Mas de uma boa maneira Comparer() é uma interface, não deve ser definida no CObject, mas como uma classe separada.
Aparentemente estáticas e constantes (isto não é OOP) não são necessárias.
Quanto ao OOP, é muito interessante como a próxima função, que tem ampla aplicação prática (não abstrata de forma alguma), pareceria em estilo processual?
Obviamente, qualquer OOP pode ser reescrito em estilo processual. Mas eu estou interessado na prática. Assim, eu levei o código acima, onde o OOP também é usado ao mínimo.
Então, quanto mais agradável/muito conveniente/muito legível/muito correto é o estilo de procedimento em comparação com o OOP neste exemplo? Bem, não para falar por algumas páginas, mas apenas para comparar o procedimento de código fonte curto com o OOP. Peço aos oponentes do OOP que mostrem uma classe mestra. Este não é o temido MT5, mas o bom e velho MT4.
Como você aprende a programar da mesma maneira? :) parece muito bonito.
Ou talvez você precise mudar sua maneira de pensar.
por exemplo, eu não sabia que as estruturas podem ser usadas quase da mesma forma que as classes, com um construtor
por exemplo, eu não sabia que as estruturas podem ser usadas quase da mesma forma que as classes, com um construtor
que moldes você pode aprender a programar exatamente da mesma maneira? :) parece muito bonito
ou talvez você precise mudar sua mentalidade também.
por exemplo, eu não sabia que estruturas podem ser usadas quase como classes, com um construtor
E posso perguntar: que gênio você vê no código do fxsaber? Talvez sejam os efeitos colaterais de IsChange que o cativaram, ou a idéia de que o estado do sistema deve ser duplicado no nível do usuário?
Posso perguntar: que gênio você vê nos códigos do fxsaber? Talvez sejam os efeitos colaterais de IsChange que o fascinam, ou a idéia de que o estado do sistema deve ser duplicado no nível do usuário?
Provavelmente porque eu mal entendo este código :)
Desculpe, sou um programador amador... Só estou familiarizado com o OOP em um nível básico
Em C++, a classe e a estrutura são as mesmas, apenas alguns padrões são diferentes.
Isso é legal, eu não sabia disso... Acho que só preciso aprender melhor os profissionais.
Portanto, você tem que aprender com os exemplos certos. E não há nenhum em SB. Tomemos como exemplo o CObject - ele não fornece controle de tipo, não fornece trabalho em nível de interface com objetos, mas contém métodos sem sentido como Save() e Load(), que nunca são redefinidos na prática. Os indicadores m_prev e m_next são usados em uma única classe CList, mas estão presentes como lastro para todas as suas classes descendentes. O mais útil é o método Comparer(). Na verdade, ela é substituída na maioria das vezes. Mas de uma boa maneira Comparer() é uma interface, não deve ser definida no CObject, mas como uma classe separada.