Uma pergunta para os especialistas do OOP. - página 9

Novo comentário
 
Roman:

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)

 
Igor Makanu:


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 :

private:
   CChartObjectButton m_button;             // chart object
..
virtual bool      OnSetColor(void)             { return(m_button.Color(m_color));                }

classe CChartObjectText : público CChartObject

classe CChartObject : público CObject :

bool CChartObject::Color(const color new_color) const
  {
//--- check
   if(m_chart_id==-1)
      return(false);
//--- result
   return(ObjectSetInteger(m_chart_id,m_name,OBJPROP_COLOR,new_color));
  }

classe CWndObj : público CWnd :

color             m_color;               // object color
...
bool CWndObj::Color(const color value)
  {
//--- save new value of parameter
   m_color=value;
//--- call virtual event handler
   return(OnSetColor());
  }


Portanto, é suficiente acrescentar uma função à classe CButton:

virtual bool      OnSetColor(uint clr)         { return(m_button.Color(clr));  }
 
Nikolai Semko:

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

 
Igor Makanu:

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.

class A
  {
public:
                     A(void)  {    };
                    ~A(void)  {    };
  };
  
class B
  {
public:
                     B(void)  {    };
                    ~B(void)  {    };
  };

class C
  {
public:
                     C(void)  {    };
                    ~C(void)  {    };
  };

struct STest
  {
   A a[];
   B b[];
   C c[];
  } test[];
 
Igor Makanu:

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á ))))))

 
Nikolai Semko:

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

 
A100:

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?

 
Alexey Viktorov:

A questão era retórica. Isso não foi claro?

A pergunta retórica contém uma declaração óbvia - não entendi o que era a declaração. Você pode explicar?
 
A100:
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.

12345678910111213141516...55
Novo comentário