My approach. The core is the engine. - page 136
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Well, if I don't publish anything big, it doesn't say I don't have anything big. It's just that I only share the little things.
You might be surprised, but I too had a moment when I started getting bogged down in procedural style. Just when I first started GUI development. After a few months of work, the code grew and got so confusing that I couldn't develop it anymore. It was a dead end.
However, that's when I came up with my approach. Create a kernel, and around it, an engine - that is, code that works with it. And it all went well.
So, my approach is not procedural style as you think.
And I've tried OOP. At some point I liked it. But only up to the moment when I saw some blatant and senseless fiddling with the code. I understood that I was just being brainwashed and started to move away from it.
There was a lot of unnecessary stuff in there. Classification for the sake of classification, crushing code for the sake of crushing, wrapping code for the sake of wrapping... None of this was consistent with the rational necessity that mechanisms require. So, I started to move away from OOP.
There was a lot of unnecessary stuff in there. Classification for the sake of classification, crushing code for the sake of crushing... None of this was consistent with the rational necessity that mechanisms require. So, I started to get away from OOP.
Bullshit!
Alas, it's not bullshit.
Drawing on canvas doesn't require a wrapper in the form of a class. A list of functions is enough. You don't need any method access rights to draw. And you know it. But you deny this fact. You deny the obvious.
It is nonsense!
No, it's not. It's simple logic.
Why would you create objects when referring to class functions, if you can refer to them directly?
I understand if you have a gigantic and convoluted class system. But you didn't create it, and still use calling functions through objects. What for?
Where is the practical necessity? There isn't. You have an abstract belief that it's necessary and that's all.
Alas, it's not nonsense.
Drawing on canvas doesn't require a class wrapper. A list of functions is enough. You don't need any method access rights to draw. And you know it. But you deny this fact. You deny the obvious.
It's not like that. My reasoning is based on simple logic.
Why would you create objects when referring to class functions when you can refer to them directly?
I understand if you have a gigantic and confusing class system. But you didn't create it, and still use calling functions through objects. What for?
Where is the practical necessity? There isn't. There is an abstract belief that it is necessary, that's all.
I just don't need to hear this nonsense. I don't think there's a single person on this forum who could teach me kanvas ( unfortunately..., I'd be glad to be wrong)
Well, there aren't many people like that around here. I'm probably one of them. Although, it's not to teach you. Just to hear a sensible answer. Why, when drawing, would you address class functions through objects, if you use only ONE class?
Why would you use a class function reference through objects when drawing if you're only using ONE class?
translate
You are working with the CCanvas class. It is the only one in your development.
The class is part of the system. If it is ONE, there is no system.
Then why create class objects and refer to its functions by OOP rules?
You PRACTICALLY don't need OOP in dealing with ONE class.
But, you do use OOP in dealing with ONE class. You don't need OOP.
You are working with the CCanvas class. It is the only one in your development.
The class is part of the system. If it is ONE, there is no system.
Then why create class objects and refer to its functions by OOP rules?
You PRACTICALLY don't need OOP in dealing with ONE class.