OOP vs procedural programming - page 39

New comment
 
Andrei:

The class has only internal variables and no input or output... Where have you seen the use in programming of such an object which in no way contacts the outside world and boils in its own juice?


Why are you arguing about something you haven't seen? A class constructor is created and it can get any number of parameters. Different child classes can have completely different sets of parameters in their constructors. You can just write methods to set parameters.

 
СанСаныч Фоменко:

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 and most importantly, problems during modification are essentially reduced. But the same result was obtained with careful observance of GOSTs, stages of development, documentation.


How many times must I tell you the same thing? OOP is not only a means of code structuring; it also contains mechanisms which are absent in your procedural programming.

This is perhaps the case when if a person hasn't seen mountains, he won't understand what it is, even if you tell him so.

 
Реter Konow:

I personally strive for versatility in solutions. This requires "splicing" similar functions into a single block without increasing the size of the code. It increases efficiency of the mechanism and there is no need in overloading and division. You just have to use your brain a bit - that's all).

That is, there were two functions of 20 lines each. Both perform similar actions or solve similar tasks. My aim is to make one function that does the job of both of them with no more than 20 lines of code. This is how I create blocks.


How long have you been poring over this library of yours?

 

For the sake of glee - R is written in an absolutely disgusting "all in one garbage can with no differentiation of access" mode. An old-school approach from twenty years ago with no areas of visibility, protection or multisession. I write as if I were the only one. Yes, the project was born under one person by unprofessional developers. It must be rewritten from scratch. At least once.

I had an idea to make a normal interface in R from MQL5, but after digging deeper into it I immediately decided not to integrate it. The system is categorically unable to protect data and sessions.

Until a programmer works in normal development teams with strict requirements (banging his hands for a couple of years at least) he will not become a developer in the normal sense. We grab our heads 90% of the time when we look at test jobs when considering candidates. Total horror throughout the development industry.

So once again - the opponents of OOP are displaying some sort of buffoonery here.

Sorry again.

 
СанСаныч Фоменко:

Wow!

I was wondering: is there any other way in today's programming to confuse an egg level problem in a cooler way?

Go up to a car standing in a traffic jam, look at how it is set up and tell the driver "is there any way to confuse the problem better, walk a hundred meters here".

As my experience shows, such "confusing problems" are much easier to understand than "problem-free" EAs made by copying from a single template with all the global variables.

 
Dmitry Fedoseev:

And why are you speculating here about something you haven't seen? A class constructor is created and it can get any number of parameters.

Read carefully, it was about the class, not the class constructor.

Moreover, you again suggest to make a monkey's work - to plant a garden on a plot when we can have access to parameters without doing ANYTHING in case of external variables or passing them directly without any unnecessary headache with constructors-destructors and all the attendant memory leaks.

 
СанСаныч Фоменко:

MyOnInit() looks about the same - a dozen lines...

So?

For Reason, in ALL of my EAs there are ten lines (if not counting inclusions and comments). 

#include <MyLib\DebugOrRelease\DebugSupport.mqh>
#include <MyLib\Factories\ForTrade\EURGBP\B1H2C20T2_0001_EPF.mq5>
#include <MyLib\Factories\ForTrade\EURGBP\B2H2C20T4_0001_EPF.mq5>
#include <MyLib\Factories\ForTrade\EURGBP\B3H2C20T2_0001_EPF.mq5>

// Объявляем фабрики частей эксперта.
CB1H2C20T2_0001_EPF epfFact_0;
CB2H2C20T4_0001_EPF epfFact_1;
CB3H2C20T2_0001_EPF epfFact_2;

// Объявляем функцию получения указателя на фабрику.
CEAPartsFactoryT* CEAPartsFactoryT::GetAdvisorsPartsFactory(uint uiFactIdx = 0)
{
   if(uiFactIdx == 0) return(GetPointer(epfFact_0)); 
   if(uiFactIdx == 1) return(GetPointer(epfFact_1)); 
   if(uiFactIdx == 2) return(GetPointer(epfFact_2)); 
   return(NULL); 
};

#include <MyLib\TSTemplate\ExpertAdvisorT.mq5>

In our case, there are three completely different TSs in one EA. They all work simultaneously, without interfering with each other.

Additional TCs can be added by declaring the appropriate factory, and adding code returning it into a function.

But the real question is not whether there are too few or too many lines of code. The question is how easy they are to maintain and modify if necessary.

SanSanych, can you easily figure out the table file provided by Peter ? And modify it easily ? Well, then you, like Peter - don't need OOP.

 
Реter Konow:
OOP is a method to separate, wrap and hide parts of a mechanism. Whether this is necessary or not is up to the developer to decide. It has nothing to do with increasing the efficiency of the mechanism at all. It structures the way of thinking, yes. It is unknown whether it structures it correctly or not. Whether it's necessary depends on a particular person, imho.

Exactly. This is the essence of encapsulation.

There's also inheritance and polymorphism.

 
Реter Konow:
OOP is a method of separating, wrapping and hiding parts of a mechanism. Whether this is necessary depends on the individual. imho.

Exactly, it depends on the individual. Why would a programmer, who is not suffering from schizophrenia, strenuously hide access to some part of his own code which he is debugging himself? Wouldn't you rather tie your own hands? :)

 
Renat Fatkhullin:

Until a programmer has worked in normal development teams with strict requirements(beaten hands on for a couple of years minimum), he/she will not become a developer in the normal sense. We grab our heads 90% of the time when we look at test jobs when considering candidates. Total horror throughout the development industry.

I wonder what this "horror" manifests itself in.

I can suppose that it has to do with the use of OOP, because in procedural programming the main attention is paid to the logic of algorithm's work and not to all sorts of external OOP-esque add-ons, with which it is very easy to build up a forest of any obtuseness.

1...323334353637383940414243444546...48
New comment
Reason: