OOP vs procedural programming - page 36
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
1. Not to any extent. Profitability does not depend on AOP.
2. In my opinion, by an order of magnitude (tenfold). But the main gain from OOP is in code support. Now I can very quickly make out the code I wrote a year or more ago. I remember well how I understood my early ANSI C programs in purely procedural style. It was much more difficult.
1. this is the main answer to the need for OOP.
2. it's a question of experience in teams. I wrote everything I needed. A couple of years ago I decided to write some more - everything reads, no problems.
From your answers I understood one thing: OOP is a certain standard which introduces the discipline of programming, introduces uniformity and on this basis, fewer errors initially and, most importantly and most importantly, it reduces the problems of modification in principle. But the same result was obtained with careful observance of GOSTs, stages of development, documentability.
I cannot understand why I have NEVER encountered anything like this in my work. Why would there be a problem of variable access differentiation for ONE developer in one not-so-big program? There would be 100 developers, each writing 100 functions. Theoretically, it could be invented. But practically, programming has evolved to OOP for almost 40 years, mountains of code have been written and I've never heard anything like that.
Well, in the beginning programs were written in code at all.
OOP is just a technology that allows you to write more complex programs faster and then maintain them more efficiently.
But it doesn't mean that OOP is a cure-all solution. I say that if you have memory like Peter, you don't need OOP at all - declare everything globally and have done with it, since you remember it all and easily allow to avoid collisions or mixing up of variables. But, I have a much worse memory. And delimitation - I use it very much. During last years I liked modifier const very much - I used it seldom before. Now I use it very often. Just to have access only to what I need and no more. So that this access is read-only in places where it is not intended to change.
George Merts:
Yes, indeed, there are situations where it suddenly turns out that it is almost impossible to get the data you need. They are hidden behind several virtual interfaces. However, this situation clearly shows that the system was originally not designed correctly, it did not provide for the transfer of this data. This situation is very unpleasant indeed. We either have to hastily build "crutches" in the form of additional interfaces, or restructure the whole system. Well... it motivates the programmer to think more carefully about the system architecture.
If the programmer is a prophet and clairvoyant, seeing ahead and in all the details of the necessary data structure for all possible variants of the main idea, then it probably makes sense to act in your way. Or do it at the final stage, when everything is already working and the code is debugged without using these add-ons, but again, provided that nothing will ever need to be changed and rearranged...
1. this is the main answer to the need for OOP.
2. it is a question of experience in teams. I wrote everything I needed. A couple of years ago I decided to write some more - everything reads, no problems.
From your answers I understood one thing: OOP is a certain standard which introduces the discipline of programming, introduces uniformity and on this basis, fewer errors initially and, most importantly, problems during modification are reduced fundamentally. But the same result was obtained with careful observance of GOSTs, stages of development, documentability.
1. No. OOP is not a tool to ensure profitability. And you cannot speak about the necessity of OOP while looking at profitability. OOP is a tool to simplify code development and maintenance.
2. It's cool when TCs of ten years ago still work. I can't live like that, they regularly stop working for me, I constantly have to modify them. And OOP is a great help to me in that.
And about OOP-some standard, yes, all true. And it's true that you can get the same result if you keep it staggered and documented. But it seems to me that it takes more effort than in the case of OOP.
In the beginning, programmes were written in code.
OOP is simply a technology that allows you to write more complex programs faster, and then maintain them more efficiently.
But that does not mean that OOP is a cure-all. I say that if you have memory like Peter, you don't need OOP at all - declare everything globally and have done with it, since you remember it all and easily allow to avoid collisions or mixing up of variables. But, I have a much worse memory. And delimitation - I use it very much. During last years I liked modifier const very much - I used it seldom before. Now I use it very often. Just so that I don't have access only to what I need and no more. So that this access is read-only in those places where it is not intended to be changed.
In the beginning, programs were written in code.
Let's not twist things around, shall we?
OOP is simply a technology that allows you to write more complex programs faster and then maintain them more efficiently.
That's questionable, and very questionable.
Faster programs are written and maintained efficiently if they have good design documentation. Echoes of this problem can be found in the marketplace, where a great deal of attention is paid to the TOR. If the TOR is lousy, no OOP will help.
Programmes that have good project documentation are written and maintained more quickly and efficiently. Echoes of this problem can be found in the marketplace, where a great deal of attention is paid to the TOR. If the TOR is lousy, no OOP will help.
If the programmer is a prophet and clairvoyant, seeing ahead and in all the details the necessary data structure for all possible variants of the main idea implementation, then it probably makes sense to act in your way. Or do it at the final stage, when everything is already working and the code is debugged without using these add-ons, but again, provided that nothing will ever need to be changed and rearranged...
OOP is simply a technology that allows you to write more complex programmes more quickly, and then maintain them more effectively.
As explained above, OOP is not originally intended for fast code writing and debugging because of the many add-on wrappers, intermediate superstructures and adapters... It only makes sense at the final stage when everything is working and debugged and the data structure has acquired its final form... That is, it is a purely cosmetic procedure of packing ready code for subsequent storage...
But another thing is more important to me - Igor correctly said above - each class is responsible only for its own variables, it is impossible to "get into" someone else's variables from it. As a result, most of the problems are cut off at the compilation stage.
A class has only internal variables and no input or output variables... Where have you seen the use in programming of such an object that has no contact with the outside world and boils in its own juice?
.... Modern programs practically don't need documentation - everything is on the palm of your hand in the class interfaces.
Explain this to the metaquotes: why did they write huge manuals for the terminal, for the language and in general, where did this mountain of documentation for software products on e.g. Cp... In fact, are there any software products without documentation? It's strange that you can't see that.