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
Em C++ o entendimento da OOP não vem de uma vez, comecei a entrar na OOP cerca de um ano e meio depois de entender a abordagem processual.
Eu também - pouco a pouco... e a compreensão plena só vem depois de 4-5 anos (e isto é normal para uma pessoa comum)
ZS: como posso mudar a cor do botão? - matar o objeto anterior e criar um novo botão de uma cor diferente? - e como obter o status de botão? - e se for um esquema de cores para centenas de botões - matá-los todos novamente e criar outros... ;)
Como isso funciona na MQ?
classe CButton : público CWndObj :
classe CChartObjectText : público CChartObject
classe CChartObject : público CObject :
classe CWndObj : público CWnd :
Portanto, é suficiente acrescentar uma função à classe CButton:
E como isso funciona na MQ?
classe CButton : público CWndObj :
classe CChartObjectText : público CChartObject
classe CChartObject : público CObject :
classe CWndObj : público CWnd :
Portanto, tudo o que você precisa fazer é acrescentar uma função à classe CButton:
tudo bem, todos os métodos OOP são assim, mesmo em MQL - eu vi o código fonte, mesmo em Delphi, mesmo em VS - a estrutura e lógica do código é sempre a mesma
Olhe, tenho este canal em meus assinantes, em geral, tenho uma visão positiva do autor, e há até mesmo uma repetição do tema de seu vídeo, que iniciou a disputa:
e há outro canal que eu gosto:
o ponto do vídeo é diametralmente oposto em termos de OOP
excluí meu posto, a discussão levará mais tempo do que planejo, duvido que esperarei por detalhes específicos, e discutir "OOP esférico" sem utilidade prática não é a melhor idéia
Todas as técnicas de OOP são assim, mesmo em MQL - observei o código fonte da SB, mesmo em Delphi, mesmo em VS - a estrutura e lógica do código é sempre a mesma
Olhe, tenho este canal em meus assinantes, em geral, tenho uma visão positiva do autor, e há até mesmo uma repetição do tema de seu vídeo, que iniciou a disputa:
e há outro canal que eu gosto:
o ponto do vídeo é diametralmente oposto em termos de OOP
excluí meu posto, a discussão levará mais tempo do que planejo, duvido que esperarei por detalhes específicos, e discutir "OOP esférico" sem uso prático, não é a melhor idéia
Para ser honesto, eu mesmo estou apenas começando a entrar na idéia do OOP. Concordo com Egor Bugaenko mais intuitivamente e com base na pouca experiência que já tenho.
Além disso, sei, de um ponto de vista puramente filosófico, que a complexidade muitas vezes leva a um beco sem saída, por isso penso que o esquema "o todo, constituído de componentes simples" é mais perfeito do que "o todo, constituído de um componente complexo".
Então, depois de assistir a estevídeo, tentarei me ater à seguinte lógica e paradigma:
Se em algum momento parecer que a única maneira de resolver o problema é através de uma complicação incômoda, então é hora de dividi-lo em elementos mais simples. Se parece impossível, significa que escolhemos um conceito errado e devemos mudá-lo e reescrever o código inteiro. Acho que isso economizará tempo no futuro.
Há muitas variações. Tudo depende do que você precisa e do que você tem imaginação para isso. Por exemplo, isto.
excluído meu posto, a discussão vai demorar mais do que o planejado
Os tópicos de Peter são um elemento impiedoso que puxa tudo em seu caminho )), isto é apenas uma introdução, à frente está a saída para o "conceito de motor central" e Peter tem mais experiência lá ))))))
Portanto, depois de assistir a estevídeo, tentarei me ater à seguinte lógica e paradigma:
Se em algum momento parecer que a única maneira de resolver o problema é através de complicação incômoda, então é hora de dividi-lo em elementos mais simples. Se parece impossível, significa que escolhemos um conceito errado e precisamos mudá-lo e reescrever o código inteiro. Acho que isso vai economizar tempo no futuro.
Em teoria isto funcionará, na prática - depende da indústria na qual você trabalhará, além do desenvolvimento de jogos, onde qualquer erro será compensado pelo hardware ou software de escritório do jogador, onde os erros não são críticos - nós o consertaremos ou reescreveremos mais tarde, há áreas onde você não pode cometer erros, eu trabalhei na automação da produção, e automação não é lâmpada, e na indústria de energia - turbinas de energia. Software e automação "um vagão e um vagão" - Rack ACS, ACS, controle de vibração, consoles de operador, e controladores e sensores de atuadores, e tudo funciona simultaneamente em um complexo, qualquer erro no conceito - na melhor das hipóteses é uma parada de emergência, na pior das hipóteses - destruição de equipamentos e danos materiais.
Qual é o objetivo? - Porque o código deve ser efetivo em primeiro lugar! Tudo o que foi criado durante anos está escrito em "uso incorreto do OOP" e inovadores... bem sentar-se com um copo de cerveja e sonhar como a humanidade Microsoft e o Google se perderam - isso é legal! mas até agora não há responsabilidade
Você foi o primeiro a me escrever (o que significa que você está preocupado), eu estava respondendo as perguntas de Alexey Viktorov sobre a Biblioteca Standard
A questão era retórica. Não foi claro?
A questão era retórica. Isso não foi claro?
Uma pergunta retórica contém uma afirmação óbvia - eu não entendi o que era a afirmação. Você pode explicar?
Uma pergunta retórica não pode de forma alguma conter uma afirmação como qualquer pergunta. Uma pergunta ainda é uma pergunta. É a mesma pergunta, mas não requer uma resposta, não espera uma resposta. Uma pergunta para lugar nenhum.