Talking about the PLO in the lounge - page 10
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 need to impose, but it is obvious that in a procedural form the logic of code is already visible without extra gestures, and each gesture of a hired programmer costs a fee to employer. Therefore if an employer is smart, he will not be fooled by OOP but a clever programmer can twist a tale about progressive OOP to get more money from him taking advantage of his low literacy. :)
Ha!
There's a "no extra effort" logic to getting around on foot, but for some reason everyone wants to take transport. It comes to the point of idiocy - they get in a car, drive two kilometres to a fitness centre, and then "wind" five kilometres on a treadmill.
Speaking of programming, in DOS a window is created simply by writing it into a video buffer. But to create a simple window in Windows - you need to register a window class, create it and run a loop of message processing - but for some reason, everyone makes these very "extra steps".
So it is here. the OOP - is chosen not at all for the "progressiveness", but for the benefits that this methodology provides, and because it is ultimately cheaper for the employer. Because having written something in procedural style you can not maintain it with the same efficiency as written in OOP style.
A good illustration - code by Peter Konov - on the one hand, quite normal procedure-oriented code, but on the other hand, to work with it you must always keep in mind a lot of information on the system structure, that personally I will not undertake such a task even for big money. At the same time, SB written in OOP-style is very easy to maintain and change. The architecture of objects in the TC pattern of the Standard Library is much more intricate than in Peter's code, however it is much easier to understand and modify.
All the talk about "a procedural style without extra work" is only up to the point when you need to write a really complex structure, and especially to make modifications to it. This is why OOP is so widely used - it is easier for programmers, and cheaper for customers. Although, to do something quite simple in it requires "unnecessary gestures". Simply, no one needs this "simple", all need "complex", which is better to be done with the use of OOP.
P.S. And I still don't understand, how you (let's speak on "You") propose to limit access to functions, which should not be used anywhere without OOP-access modifiers?
George Merts:
Because if you write something in procedural style, you won't be able to maintain it with the same efficiency as something written in OOP style.
P.S. And I still don't understand, how you (let's speak on "you") propose to limit access to functions, which should not be used anywhere without OOP access modifiers ?No, no. It is just the other way round.
It is just OOPeshe code which is difficult to maintain and modify for there is a lot of various twists and turns in it that later it is easier to write the code once again. In fact, it is said, that the purpose of OOP is to hide logic, so they have hidden it, and if suddenly it is necessary to uncover it, this is a service with additional charge.
Wrapper function allows to hide internal functions, but if you suddenly feel like adding this internal function, you can hide it in a DLL, or source code in a separate file, and the file in the furthest directory, so that even if you try it will not be found, maybe there are more options for especially raging programmers. :)
No, it's not. It is just the other way round.
The OOP code is just the same difficult to maintain and modify, because the logic there is hidden with a lot of different tricks, that then it is easier to rewrite the code. In fact it is said that the purpose of OOP is to hide the logic, so they have hidden it, and if suddenly it is necessary to uncover it, this is a service with additional charge.
Wrapper function allows you to hide the internal functions, but if you suddenly want to add this internal function for anything, you can hide it in a DLL, or source code in a separate file, and the file in the furthest directory, so that at best desire it could not be found, maybe there are options for particularly raging programmers. :)
Why would it be "difficult to modify" if logic is hidden? That's why logic is hidden, to prevent you from modifying anything where it cannot be done.
It's just in procedural approach you want to change something, changed it, and then you don't understand why it doesn't work (or worse - sometimes you get incomprehensible errors). And in OOP approach you want to change it - and you don't have any access to class internals. And if there is no access, it means that it's done for a reason, there is something tricky there, some implicit conditions of use. Respectively, if you want to change something, you can take that very class, inherit your own class from it, and change there what you need since you already have access to the protecte-methods in the descendant.
And even if you inherit it, you can stumble upon a private method or field that is unavailable even in the descendant, and once again, for a reason, it means that this field is not intended to be changed even in the descendant.
Talking about "hide in DLL" - the problem is that you can only hide ALL of it in a DLL. Not a part of object. And that's what the access modifier is for, to hide only part of object. That is why everything is conceived - to allow the programmer in each place of the program to have access only to what he needs, and nothing "from above" - this allows not to be afraid that he could accidentally change not what he needs, but could change the part, which is allowable for modification. What is the point of the DLL then? Open the DLL code - then the whole code is opened, not parts. Close - again, all access is closed.
I do not know how to limit access in procedural style without using private-protected-public sections. And this restriction helps me a lot.
Why would it be "hard to modify" if the logic is hidden? The logic is hidden so that you can't modify anything where you can't.
It's just in procedural approach you want to change something, changed it, and then you don't understand why it doesn't work (or worse - sometimes you get incomprehensible errors). And in OOP approach you want to change it - and you don't have any access to class internals. And if there is no access, it means that it's done for a reason, there is something tricky there, some implicit conditions of use. Respectively, if you want to change something, you can take that very class, inherit its own class and change there what you need, since you already have access to the protecte-methods in the descendant.
And even if you inherit it, you can stumble upon a private method or field that is unavailable even in the descendant, and once again, for a reason, it means that this field is not intended to be changed even in the descendant.
Talking about "hide in DLL" - the problem is that you can only hide ALL of it in a DLL. Not a part of object. And that's what the access modifier is for, to hide only part of object. That is why everything is conceived - to allow the programmer in each place of the program to have access only to what he needs, and nothing "from above" - this allows not to be afraid that he could accidentally change not what he needs, but could change the part, which is allowable for modification. What is the point of the DLL then? Open the DLL code - then the whole code is opened, not parts. Close it - again, all access is closed.
I don't know how you can limit access in procedural style without using private-protected-public sections. And this restriction helps me a lot.
George, you're beating the drum again )))) This makes no sense.
Georges, you're beating around the bush again )))) It doesn't make any sense.
Maybe, maybe.
But you're a part-time Casanova... And I'm a part-time tutor. I see that "the client is not lost." So I keep explaining. Like "professional deformity".
Maybe, maybe.
But you're the part-time Casanova... And I'm a part-time tutor. I see that "the client is not lost". So, I keep explaining myself. Like "professional deformity".
I've had it with the Casanovas. You made up a fairy tale and believed in it yourself) like a kid believes in Father Christmas, for God's sake.)
There is no need to impose it, but it is obvious that in the procedural form the logic of the code is already seen without extra gestures, and each gesture of a hired programmer costs the employer money.
The number of gestures in the above procedure code will need more if changes need to be made.
It is possible to write code without functions (procedures). But coding eventually stopped being written through "pouring concrete" and started to build from "bricks". Hence came procedural programming.
OOP is another step in breaking down the overall work into simpler components.
The division of labor and, as a consequence, the conveyorization of the production of anything created the industrial revolution, which led to the industrialization of mankind.
Hand-made is "writing code without procedures".
Conveyor is "procedural code writing", where many elements of the conveyor are dependent on the others. That is, changing one element may require changing another.
"OOP programming" is a pipeline with reduced dependency between elements. That is, one element can be replaced by another and the pipeline is less likely to stop working. Being able to break down any production into independent parts, inputting standards, etc. - is Object Oriented Manufacturing (not programming).
Programming itself is a special case of production. The OOP approach is a principled approach to producing anything. Therefore, it is very narrow to talk about programming. OOP was successfully applied BEFORE it appeared in programming.
I've had it with the Casanovas. You made up a fairy tale and believed in it yourself ) like a child believing in Father Christmas, for God's sake )
I envy you, Lech!
Quite seriously. Well, leave me the right for a little artistic hyperbole...
The number of bodily movements in the above procedural...
О ! Well said.
Fully supportive.
The amount of bodily effort in the above procedure code will need to be greater if changes need to be made.
In principle, the amount of bodily effort in OOP cannot be less, since all these interfaces are additional overhead, which often exceeds the cost of writing the logic itself. And this is despite the fact that any function already has an interface, i.e. it is proposed to make another hedge, 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?