A question for OOP experts. - page 9

[A100]

Roman:

In C++ understanding of OOP comes not at once, I started to get into OOP about a year and a half later after understanding procedural approach.

So did I - little by little... and full understanding comes only after 4-5 years (and this is normal for an ordinary person)

[Nikolai Semko]

Igor Makanu:

ZS: how do I change the colour of the button? - kill the previous object and create a new button in a different colour? - and how to get button status? - and if it's a colour scheme for hundreds of buttons - kill them all again and create others? ;)

How does this work in MQ?

class CButton : public CWndObj :

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

class CChartObjectText : public CChartObject

class CChartObject : public 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));
  }

class CWndObj : public 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());
  }

Therefore, it is sufficient to add a function to the CButton class:

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

[Igor Makanu]

Nikolai Semko:

And how does this work in MQ?

class CButton : public CWndObj :

class CChartObjectText : public CChartObject

class CChartObject : public CObject :

class CWndObj : public CWnd :

So all you have to do is add a function to the CButton class:

all the OOP methods look like this, even in MQL - I've seen the source code, even in Delphi, even in VS - the code structure and logic is always the same

Look, I have this channel in my subscribes, in general, I have a positive view of the author, and there is even a repeat of the theme of your video, which started the dispute:

and there's another channel that I like:

the point of the video is diametrically opposed in terms of OOP

deleted my post, the discussion will take longer than I plan, I doubt I'll wait for specifics, and discussing "spherical OOP" without practical usefulness is not the best idea

[Nikolai Semko]

Igor Makanu:

All the techniques of OOP look like this, even in MQL - I watched the source code of SB, even in Delphi, even in VS - the code structure and logic is always the same

Look, I have this channel in my subscribes, in general, I have a positive view of the author, and there is even a repeat of the theme of your video, which started the dispute:

and there's another channel that I like:

the point of the video is diametrically opposed in terms of OOP

deleted my post, the discussion will take longer than I plan, I doubt I will wait for specifics, and discussing "spherical OOP" without practical use, is not the best idea

To be honest, I myself am only just beginning to get into the idea of OOP. I agree with Egor Bugaenko more intuitively and based on the little experience I already have.
Moreover I know from purely philosophical point of view, that complication often leads to a dead end, so I think that the scheme "the whole, consisting of simple components" is more perfect than "the whole, consisting of one complex component".
So after watching thisvideo, I will try to stick to the following logic and paradigm:
If at some point it seems that the only way to solve the problem is through a cumbersome complication, then it is time to break it down into simpler elements. If it seems impossible, it means that we have chosen a wrong concept and must change it and rewrite the whole code. I think this will save time in the future.

[Konstantin Nikitin]

There are many variations. It all depends on what you need and what you have the imagination for. For example this.

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[];

[[Deleted]]

Igor Makanu:

deleted my post, the discussion will take longer than planned

Peter's topics are a ruthless element that pulls in everything in its path )), this is just an introduction, ahead is the exit to the "core-engine-concept" and Peter has more experience there ))).

[Igor Makanu]

Nikolai Semko:

So after watching thisvideo I will try to stick to the following logic and paradigm:
If at some point it seems that the only way to solve the problem is through cumbersome complication, then it's time to break it down into simpler elements. If it seems impossible, it means that we have chosen a wrong concept and need to change it and rewrite the whole code. I think it will save time in the future.

In theory this will work, in practice - it depends on the industry in which you will work, apart from game development, where any error will be compensated by gamer's hardware or office software where errors are not critical - we will fix or rewrite it later, there are areas where you cannot make mistakes, I worked in production automation, and automation is not light bulbs, and power industry - power turbines. Software and automation "a wagon and a wagon" - Rack ACS, ACS, vibration control, operator consoles, and controllers and sensors of actuators, and it all works simultaneously in a complex, any error in the concept - at best it is an emergency stop, at worst - destruction of equipment and property damage.

What is the point? - Because the code must be effective in the first place! All that has been created for years is written on "incorrect use of OOP", and innovators... well sit down with a glass of beer and dream about how mankind Microsoft and Google went astray - that's cool! but so far there is no accountability

[Alexey Viktorov]

A100:

You were the first to write to me (which means you are concerned), I was answ ering Alexey Viktorov's questions about the Standard Library

The question was rhetorical. Wasn't it clear?

[A100]

Alexey Viktorov:

The question was rhetorical. Wasn't that clear?

The rhetorical question contains an obvious statement - I didn't understand what the statement was about. Can you explain?

[Alexey Viktorov]

A100:
A rhetorical question contains an obvious statement - I did not understand what the statement was. Can you explain?

A rhetorical question can in no way contain an assertion like any question. A question is still a question. It is the same question, but it does not require an answer, does not expect an answer. A question to nowhere.