Talking about the PLO in the lounge - page 11
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
The amount of gestures in OOP cannot be less in principle, because all these interfaces are additional overhead, which often exceeds the cost of writing the logic itself. And this despite the fact that any function already has an interface, i.e. it is proposed to build another garden, which is essentially meaningless.
At the same time, any change in the code, both in interface and function, becomes much more complicated, since one is hooked on the other, which means that we have at least a quadratic increase in the possible number of bugs and labor-intensiveness... It's kind of obvious, isn't it?
The amount of gestures in OOP cannot be less in principle, because all these interfaces are additional overhead, which often exceeds the cost of writing the logic itself. And this despite the fact that any function already has an interface, i.e. we have to make yet another hedge that is essentially useless.
In this case any change of code in both interface and function becomes much more complicated, as one is hooked on the other, i.e. we have at least quadratic increase of possible bugs and labor-intensiveness... It's kind of obvious, isn't it?
Forum on trading, automated trading systems and trading strategies testing
Talking about OOP in the backyard
fxsaber, 2018.01.14 11:35
Programming itself is a special case of production. The OOP approach is a principled approach to producing anything. So to talk about programming is very narrow. OOP was successfully applied BEFORE it appeared in programming.
The history of industry came to object-oriented PRODUCTION as the next stage of conveyorization. So to talk about OO programming is a narrow view. Like talking about OO sewing boots. We are talking about algorithmic approaches to the organization of any production, including, as a very special case, the creation of software.
OOP production has proven competitively superior to conventional assembly lines. There is short-term planning of production, when it is necessary to make it work now. And there's long term - when you lay a lot of "extra" at the moment, but that foundation is conducive to simply scaling up production. Again, it's not about programming, it's about general approaches in creating production.
OOP approaches can be seen even in modern institutions of power.
The terminal is a class in relation to your code. How often do you need to change something in the terminal code?
This example is incorrect. We are talking about interfaces within your program...
The history of industry came to object-oriented PRODUCTION as the next step in conveyorisation.
OO programming also has its processing pipelines and OOP introduces another layer of abstraction which only increases the overhead of each individual conveyor and the entire production.
OO programming has its own processing conveyors too, and OOP introduces another level of abstraction that only increases the overhead of each individual conveyor and the entire production.
You are stupid, unfortunately. You are told about the history of the industry and about OOP as one of the stages in that history, which has played a huge role in all the material (and not only) things around you. And you keep talking about a special case of programming.
Ignorance of the History of Human Development. You will not leave a trace in the memory of your direct descendants.
You are told about the history of the industry and about the OOP as one stage in that history, which has played a huge role in all the material (and not only) things around you.
Your naive attempt to drag the PLO into the history of industry is amusing, but sadly illiterate.
This example is incorrect. We're talking about interfaces within your program...
Why is it "incorrect"?
How is a program different from ALL software running on a computer?
After all, it is the same series of instructions and data sets as in any user program. Why is it incorrect - here or there, one part of the software has no access to another part of the software other than through established exchange protocols ?
It's okay, if you program seriously - sooner or later you will come to the need for differentiation of access rights.
I too, back in the days of switching from real to secure mode, hated that I couldn't access any physical memory address. I even made twists with a DMA controller that copied data from protected system area to mine (though it was rather difficult to make out what was copied there, so I didn't). In my youth I was indignant - how could I have no direct access - it was almost an infringement of my rights... And what about the programme to make something unavailable to me?
Well, as I grew up with experience, I often found out that differentiation of access rights is a boon for the programmer himself, because it often saved me from making errors in written modules. You take a class, you want to use it, and it has no access to some data... You are indignant, how could it be, you start to look into it... and oops... There are things that need to be taken into account and the data cannot be accessed directly, there are "indirect paths", the system architecture is such that by accessing it directly I may get invalid data. But I can also get valid data - it all depends on the point in time. And such an error is very hard to detect.
Here, the simplest issue is accessing data in a cache. If you need cached data and you access it directly - are you sure you'll get the right data? In procedural approach without differentiation - you have to understand when you can use it, when you can't, when data are valid, when they aren't... In OOP approach - everything is very simple, you don't have access to cache data, you can only call function, which returns the required data, and if it's invalid, it fetches valid data. Is it "more complicated"? Now imagine, that you use this cache one year after writing it. When you have completely forgotten the principles of cache refreshing and validity definition. In OOP-approach you don't care. The class function will provide you with everything. But in functional approach - you have to remember in details, when and how cache is updated, when data in it are valid and when not.
This example is incorrect. We are talking about interfaces within your programme...
The terminal is a class in relation to your code. How often do you need to change something in the terminal code that is hidden from you and only provided with public methods - functions to implement your programs.
+++ )))
The terminal is a class in relation to your code. How often do you need to change something in the terminal codethat is hidden from you, and only public methods - functions for implementing your programs are provided.
Such a need arises regularly. It is only desirable that the developers do this.
A simple example. For some reason, the developers did not consider it necessary to provide a horizontal coordinate grid for indicator charts. And of course, they haven't provided an appropriate method for that).