My approach. The core is the engine. - page 137
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
Peter, you really misunderstood something about the application of OOP.
Nikolai, are you building HIERARCHY or creating drawing mechanisms?
If you build HIERARCHY (don't care about drawing), then it's clear why you need OOP everywhere.
If you're creating a drawing mechanism that works on the basis of ONE class, then you don't need Class itself.
Class, - from the word Classification. Classification is a division by attributes. Class is a derivative of Classification. If there is one Class, then there is no Classification.
So Class, in that case, is abstract bullshit. It doesn't make sense.
...
One gets the impression that the OOP itself gets ahead of the mechanism it is supposed to serve. That is, the mechanism must strive for integrity, hence for the smallest number of its blocks. But OOP forces these blocks to multiply for any reason. As the result the structure of mechanisms is tattered and they do not work well. And they develop even worse.
...
Well, maybe you should study OOP at least a bit instead of fantasizing about it? You don't even fantasize, you are delirious.
Nikolai, has it ever occurred to you that your love for OOP is not justified by almost anything but abstract reasons?
Say, if you were creating gigantic mechanisms with this OOP, it would be clear why you need it so much. You would specifically justify why you need OOP. But, you create relatively small mechanisms. There is not enough code there to draw conclusions about disadvantages and advantages of this or that approach. But you keep talking about OOP anyway. While OOP is just a tool, and has no sense by itself. That is if there is no mechanism to be made, OOP is not necessary. But if there is a mechanism, it should be serious enough to require OOP while creating it.
Most of those who stand up for OOP do not make anything serious. They only do small things. However, their belief in OOP is unshakable. Others who make much more serious mechanisms are much less likely to shout about the greatness of OOP. Some even speak out with criticism (there have been a couple of times).
So, your argument needs to be backed up by practice, not just theory. I, for example, can argue about the benefits of OOP in GUI development with Anatoly, because we can compare solutions and their nuances in practice. But, with you, I can't deploy my argument because you won't understand it. You will, but you won't understand it (no offence). Anatoly, on the contrary, can understand it very well. The difference in experience of creating global mechanisms is the main reason for misunderstanding.
SZY. As a practitioner I will tell you this: The approach must be such that it would maximize the potential of the brains of a particular programmer. I have found such an approach for myself.
Fantasies about OOP are getting wilder and wilder...
The seriousness of work is determined by the result, not by the number of years spent.
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're denying the obvious.
Oh! Yes. To eat a banana, you have to peel the skin. But if a cow has horns, then everyone with horns is a cow.
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 refer to the class functions through objects, if you use only ONE class?
Because the drawing functions on the canvas only refer to drawing on the canvas and nothing else, so there's no reason to keep them in a separate bin, that's why they are collected in one class. But you wouldn't understand it anyway.
Nikolai, are you building HIERARCHY or creating drawing mechanisms?
If you build HIERARCHY (don't care about drawing), then it's clear why you need OOP everywhere.
If you're creating a drawing mechanism that works on the basis of ONE class, then you don't need Class itself.
Class, - from the word Classification. Classification is a division by attributes. Class is a derivative of Classification. If there is one Class, then there is no Classification.
So Class, in that case, is abstract bullshit. It doesn't make sense.
What does hierarchy have to do with it? OOP makes extensive use of inheritance... ...and yet another bunch of rampant fantasy...
...and the cherry on top of the cake:
I had a similar project with another rather expensive piece of software, and I also implemented the idea using workarounds (so as not to buy additional modules).
I had a similar project on another, rather expensive piece of software, also implemented the idea via workarounds (so as not to buy additional modules), it worked, but with some customers ended up in a deadlock and the time was wasted
But it was a completely different sphere, and it was easy to find customers