My approach. The core is the engine. - page 18
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
No, while we are discussing about casual programming, I'm dragging the blanket to OOP, the topic-starter is still holding on! He writes that everything can be kept in his head - well, casual programming)))
Core-engine
Casual programming )))
Casual programming :)
Casual programming :)
Maybe you're right, I remember the term - a couple of months ago on another forum guy called himself a casual programmer, I even tried to clarify what it could mean, my knowledge of the word casual is associated only with Android game - "Zuma", it turned out that it is a programmer who programs randomly - from occasion to occasion ))))
OOP is a very flexible methodology, so it does not have any a priori ideas like the concept of "kernel". However, the kernel model in question here can very well be built using OOP. Therefore, the statement is not entirely correct.
No, OOP has nothing to do with it at all. The kernel is Unix, we assemble everything around the kernel; the shell is everything that is like Windows, we strip away what is superfluous and work with the rest. In general, this is about an operating system.
Cajun programming :)
Cajual, don't worry.
What repulses me about OOP is the rigid format of writing code. As you've seen, I tend to make large data tables and find it very practical. In OOP I have to adhere to a bunch of rules, which I personally find very constraining.
In short, I program with a different OOP. My own. There are few rules and a lot of freedom. Functionality itself is stacked into large blocks, and data is organized in kernels. I don't even specially think through their structure. Everything develops on its own. At the intuitive level.Peter, those rules are the ones you yourself need. That's why they're "stiffening" you. So that you don't accidentally mess up and get into something you're not supposed to. In fact, OOP-style is 'rules of the road' - of course, they restrict the driver. And in a village with three yards - no one looks at them, it's easier and faster (more efficient). However, in a big city, it's the opposite - it's the traffic rules that enable the most efficient transport connections. It's the same with the AOP. They are the rules that allow you to build large complex systems in the most efficient way.
In your system - there just hasn't been any change yet, it's very limited in use, and doesn't need modifications. That's why you can keep it in your head. It's OK if the system gets users and needs modifications - the lack of control and encapsulation will be quite stressful.
Everything else - no difference, OOP and your style (as said, you have procedural style as well - also suffers from the same flaws - global variables, lack of type control, and so on) are otherwise close.
In defense of your style you need to prove the only thing - that keeping the whole system in a huge global array with arbitrary access is better than breaking the program into a bunch of small parts nested in inheritance chains with polymorphic access, and hidden by encapsulation.
By the way, there are people on the forum who don't like inheritance - I think they may support you.
Another advantage of using OOP, as opposed to Peter's method. In OOP, the programmer does not need the source code of the base class and does not need to understand how it works. In order to extend or change the functionality of the base class, it is sufficient to create an heir of this class.
If you use Peter's method, the programmer needs to understand all the long code, and if there is no source code, you will have to write it from scratch.
Everything else - no difference, OOP and your style (as already mentioned, you have a procedural style - also suffers from the same drawbacks - global variables, lack of type control, and so on) are otherwise close.
i could be wrong, and googling is too lazy, but the procedural style implies a logical completeness of a procedure (function) - "unscrew" it from the source and use it in other code, ie the built-in MQL functions take data as parameters and return the result.... and here, Piotr has fallen on both feet )))) - Exchange through globally declared variables reduces the portability of the code and allows for hard to track bugs ;)
All right. Let's say I'm convinced.
In principle, I have understood all this for a long time. And I agree with it. However, at the same time, I prefer my own approach. Why?
There is one particular reason:
PROGRAMME DEVELOPMENT.
//---------------------------------------
How fast will the program develop with OOP and with my approach? Which approach is more favourable for growth and complication of mechanisms?
I have concluded that my approach + native language in the code (60% Russian and 40% of English), give a maximum rapid growth of the program.
Precisely this rapid growth is what I need. Not digging in the details. Not just hovering over each line of code. Not a professional approach.
I wanted the program to quickly develop and become more complex. That mechanisms would be created to perform the functions assigned to them. Quick and easy.
So that you could add new features with a few lines of code.
My approach is superior to OOP in solving this particular task.