Кто-нибудь создал успешную автоматизированную торговую систему? Что вы посоветуете? - страница 16

Новый комментарий
 
Aleksei Stepanenko #:
Отлично! Как на счёт профита с ООП. Сразу пойдёт после изучения?

ООП дает вам возможность писать компактный, понятный элегантный код. Вы тратите на написание, модификацию и отладку кода в несколько раз меньше времени, которое стоит очень дорого. Можете построить значительно более сложную торговую систему и опробовать значительно больше торговых вариантов. Разумеется, если у вас нет идей профитного бота - то лучше вообще ничего не делать. Кроме этого, не забывайте о вероятности прямого убытка в случае баг, вероятность которых в хорошем ООП коде в разы меньше.

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

ООП дает вам возможность писать компактный, понятный элегантный код.

Это не так.

 
PapaYozh #:

Это не так.

Ну, если поставить задачу специально усложнить - то да, с ООП возможностей для намеренного усложнения больше. 

Но, если не уподобляться Мартышке с Очками - то код с применением ООП получается заметно понятнее, структурированнее и удобнее в поддержке. 

 

Да я не против ООП, друзья. Мне нравится его объектная идея. И я использую его частично, правда в виде структур, вернее, массива структур. Этого достаточно в трейдинге, чтобы адресно хранить все данные с графика и не гонять циклы на каждом баре. Но, думаю, более и не требуется здесь. Конечно, можно все писать в ООП, кто привык. Но до профита им также далеко, как и процедурникам. Весь вопрос в прибыльной системе, если она есть, то можно и goto-кодом написать :)

Тема ветки парит над способом её решения.

 
Aleksei Stepanenko #:

И я использую его частично, правда в виде структур, вернее, массива структур.


В Java это даже имеет своё название: POJO (Plain Old Java Object)

;)

 
Georgiy Merts #:

 код с применением ООП получается заметно понятнее, структурированнее и удобнее в поддержке. 

Это далеко не всегда так и зависит не от ООП, а от чистоты кода, от нейминга.

 
Aleksei Stepanenko #:

Да я не против ООП, друзья. Мне нравится его объектная идея. И я использую его частично, правда в виде структур, вернее, массива структур. Этого достаточно в трейдинге, чтобы адресно хранить все данные с графика и не гонять циклы на каждом баре. Но, думаю, более и не требуется здесь. Конечно, можно все писать в ООП, кто привык. Но до профита им также далеко, как и процедурникам. Весь вопрос в прибыльной системе, если она есть, то можно и goto-кодом написать :)

Тема ветки парит над способом её решения.

Использование структур не является ООП. Все приемущества ООП начинаются, когда вы начинаете использовать паттерны ООП. Наследование, синглтоны, фабики обьектов, интерфейсные классы и т.д. Кроме этого,  без ООП не обойтись тогда, когда вас в команде более 2 человек. Например:

enum Direction
{
  BUY,
  SELL,
  NO_SIGNAL
};

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

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

Далее, либо сами, либо раздаете 3 людям писать сигналы, например, по 3 разным индикаторам:

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

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

В месте, где используется сигнал достаточно сделать:

Signal* signal;

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

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

Вы, как сеньор, полностью абстрагированы от реализаций тел функций. Для вас не важна реализация и какой индикатор используется. Вы просто используете check_signal и все. В данном примере, используется одна функция. А если в классе функций много - вам придется switch вставлять в любое место, где реализация зависит от конфига или иного выбора. Кроме этого, если вы используете базу данных или скажем, лог файл в куче мест - вам приходится делать глобальную переменную и на всех этапах контролировать ее состояние (открыт ли файл или база и т.д.). В случае, если для этих целей вы используете синглтон - вы можете быть уверены, что где бы вы не использовали объект лог файла/базы - всегда будет создана одна копия объекта в которой вы можете переоткрыть базу/файл, использовать флаги состояний, делать буферизированый лог для того, что бы не писать на диск в каждом выводе и т.д. Если у вас код более 10 000 строк - то функциональщина превращается в сущий ад для разработчика. А через пол года, когда вы забудете половину своего кода - переразобраться в нем будет сущий ад. Кроме этого, хороший ООП дизайн позволяет добавлять новый функционал или править старый не боясь что все полетит к хренам если вы где то что о дрните.

 
Valeriy Yastremskiy #:
А в чем разница в ООП в 5ке и 4ке? Просветите. Разница в настройках биржевого окружения явная. Ну бары с конца нумеруются. Явных других отличий по языку не вижу.

Как миниум, наконец избавились от кучи функций телескопов и самое главное, была добавлена стандартная библиотека с огромным количеством полезных классов.

 
Знание ООП как-то приблизит мою мечту сделать из 100 баксов 200?
 
Вадим Калашнков #:

Как миниум, наконец избавились от кучи функций телескопов и самое главное, была добавлена стандартная библиотека с огромным количеством полезных классов.

особенно Object.mqh

прямо по книжкам которые вы неудачно цитируете..блестящий паттерн :-)

Тема вообще не про то насколько вы освоили курс ООП и научились его адвокатствовать.. на мой взгляд хреновато освоили

в общем, собирай учебники и завтра марш в школу

1...91011121314151617181920212223...62
Новый комментарий