Has anyone created a successful automated trading system? What is your advice? - page 16

 
Aleksei Stepanenko #:
Great! What about profit with OOP. Will it go right away after you learn it?

OOP gives you the ability to write compact, clear, elegant code. You spend several times less time writing, modifying and debugging code, which is very expensive. You can build a far more sophisticated trading system and try out far more trading options. Of course, if you don't have any ideas for a profitable bot - then it is better not to do anything at all. Besides, do not forget about probability of direct loss in case of bugs, the probability of which in good OOP code is much less.

 
Вадим Калашнков #:

OOP gives you the ability to write compact, clear, elegant code.

It doesn't.

 
PapaYozh #:

This is not the case.

Well, if you set a task to complicate it deliberately, then yes, there are more opportunities to complicate it deliberately with OOP.

But if you don't become like Monkey with Glasses, you get much clearer, more structured and maintainable code with OOP.

 

I'm not against OOP, friends. I like its object idea. And I use it partially, but in the form of structures, or rather an array of structures. It's enough in trading to store all data from a chart and not to run loops on every bar. But I think that this is all we need. Of course, one can write everything in OOP, those who are used to it. But they are as far from profitable as procedural ones. The whole question is in profitable system, if you have it, you can write it by goto-code :)

The topic of the branch is hovering over the way to solve it.

 
Aleksei Stepanenko #:

And I use it partly, though in the form of structures, or rather, an array of structures.


In Java it even has its own name: POJO (Plain Old Java Object)

;)

 
Georgiy Merts #:

OOP code is noticeably clearer, more structured and easier to maintain.

This is not always the case and depends not on OOP, but on code cleanliness, on naming.

 
Aleksei Stepanenko #:

I'm not against OOP, friends. I like its object idea. And I use it partially, but in the form of structures, or rather an array of structures. It's enough in trading to store all data from a chart and not to run loops on every bar. But I think that this is all we need. Of course, one can write everything in OOP, those who are used to it. But they are as far from profitable as procedural ones. The whole question is in profitable system, if you have it, you can write it by goto-code :)

The topic of the branch is hovering over the way to solve it.

Using structures is not OOP. All the benefits of OOP start when you start using OOP patterns. Inheritance, singletons, object facets, interface classes, etc. Also, you can't do without OOP if you have more than 2 people in your team. For example:

enum Direction
{
  BUY,
  SELL,
  NO_SIGNAL
};

class Signal
{
public:
  Signal() {}
 ~Signal() {}

  virtual Direction check_signal() { return NO_SIGNAL; }
};

Next, either yourself or give 3 people to write signals, for example, for 3 different indicators:

class RSISignal : public Signal
{
public:
  RSISignal() {}
 ~RSISignal() {}

  Direction check_signal() 
  { 
    Direction result;
    // Checking signal with RSI
    return result;
  }
};

The place where the signal is used is enough to do:

Signal* signal;

switch signal_type
{
  case RSI : signal = new RSI;
  case CCI : signal = new CCI;
  case MA  : signal = new MA;
};

if (signal.check_signal())
.....

You, as a senor, are completely abstracted from function body implementations. The implementation and which indicator is used is not important to you. You just use check_signal and that's it. In this example, one function is used. And if there are many functions in a class - you have to insert switch wherever the implementation depends on config or other choice. Also, if you use a database or say, a log file in a bunch of places - you have to make a global variable and control its state at all stages (whether the file or database is open, etc.). In case you use singleton for this purpose - you can be sure that wherever you use log file/base object - there will always be one copy of object where you can reopen base/file, use state flags, make buffered log so you don't write to disk in every output, etc. If you have more than 10,000 lines of code, the functionality is a living hell for the developer. And in half a year when you have forgotten half of your code it will be a living hell to rework it. Besides, good OOP design allows you to add new functionality or edit the old one without fear that everything will go to hell if you change something somewhere.

 
Valeriy Yastremskiy #:
What's the difference in OOP in 5 and 4? Enlightenment. The difference in stock environment settings is obvious. Well the bars are numbered from the end. I do not see any other obvious differences in the language.

As a minimum, a bunch of telescope functions were finally gotten rid of and, most importantly, a standard library with a huge number of useful classes was added.

 
Will knowledge of OOP somehow bring me closer to my dream of making 200 quid out of 100?
 
Вадим Калашнков #:

As a minimum, finally got rid of a bunch of telescope functions and most importantly, a standard library with a huge number of useful classes was added.

especially Object.mqh

right from the books you unluckily quote...brilliant pattern :-)

The topic isn't about how well you've mastered the OOP course and learned to advocate it... in my opinion it's a shitty mastering

Anyway, get your textbooks and go to school tomorrow.