Вопросы по ООП в MQL5 - страница 29

 
Dmitry Fedoseev:

Да, тут вот еще один вопрос постоянно возникающий и не имеющий однозначного ответа. Когда возникает необходимость наследовать собственный класс - что лучше сделать, наследовать его или написать новую расширенную версию своего класса.

тут от общего видения что хотите в итоге все зависит, имхо

если дальше планирую где то использовать класс, то нужно завершить его без наследования

в моем примере класс CError умеет получить GetLastError(), распринтовать с описанием и возвратить значение (int) ошибки, его планирую использовать везде, все равно там только конструктор который определяет язык в статик переменную и сами case возвращающие текст ошибки

а вот есть еще довольно полезный метод bool              ServerDisable(); - это определяет доступность сервера (код мультиплатформенный МТ4/МТ5), очень хорошая функция, вроде и нужна еще где то в другом участке кода, а вот подумал, что все равно буду использовать при совершении торговых операций - воткнул в класс COrder 

.....

а если захочу трейлинг использовать его куда?.... тут поле для фантазии конечно большее, но в итоге все равно как обьект в COrder пойдет - где его еще использовать?


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

в процедурном стиле вот весь этот класс довольно компактнее будет, вот показывал пример для функции открытия ордера которая умеет хранить в статик константы обьема ордера  https://www.mql5.com/ru/forum/85652/page17#comment_12805083

 
Dmitry Fedoseev:

А это принципиально важно - оставаться в каких-то рамках? Если важно оставаться в рамках - то можно и функции написать. 

Я отвечал в контексте вашего сообщения о том, что мол если не использовать классы, то придётся заморачиваться с неудобными сигнатурами вызовов.  Я показал, что заморачиваться необязательно.

 
Alexey Navoykov:
Что мешает передавать в конструктор название символа, сделав класс гибким и универсальным?  Возможность портфельной торговли принципиально не рассматриваете?

рассматриваю все,

но  пока застрял на исследованиях - сейчас почти готовы 1000 и 1 способ ММ исследовать и всякие трюки с ордерными системами )))

но я все равно считаю, что не слишком это гибко в итоге, выше уже 2 раза писал, что оптимальнее процедурный стиль + небольшие классы "дергающие" отлаженные функции работы с ордерами

в общем пока на тестирование идей переключусь, там видно будет что в коде правлю часто, что не трогаю

 
Igor Makanu:

.....

а если захочу трейлинг использовать его куда?.... тут поле для фантазии конечно большее, но в итоге все равно как обьект в COrder пойдет - где его еще использовать?


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

***

Трейлинги и прочие подобные функции сопровождения хорошо бы сделать потомками одного класса, а их экземпляры создавать в массив. Если функция включена - в массив добавляется экземпляр и он исполняется. Если все функции выключены, то массив пустой и лишние if не выполняются. Можно хоть 100 трейлингов вставить в советника и это не повлияет на скорость его работы.

 
Alexey Navoykov:
Так не делается. Нужно как минимум вызывать как Bid() и Ask().  У вас выглядит как просто переменная, создавая видимость что её значение сохраняется неизменным, хотя в реальности это не так.

увы, так делалось всегда, в МТ4 так и осталось Bid и Ask и никаких прихотей Создателя разрушить это простое использование и получение текущих цен ;)

fxsaber:

У меня следующая схема, где проблем не испытывал.

  1. Пишу ТС только для Тестера. Логи, обработчики ошибок и прочая муть отсутствуют. Код получается очень лаконичный, понятный и поддатливый на правки, если делать через ООП (но не принципиально). В КБ пример выкладывал. Бонус - быстрая оптимизация.
  2. Главное, чтобы для Тестера и чтобы по независимым блокам было раскинуто. Формирование торговых сигналов - один блок. Проторговка сигнала - другой.
  3. Перевод на реал делается всегда в несколько одних и тех же движений. ТС без правки кода помещается в виртуальное окружение. Можно сразу несколько ТС в одно окружение или каждую ТС в свое, тогда ООП становится особенно удобен. Далее берется копир (в Маркете их полно, так что народ руку набил на копир-логике), который просто копирует сделки/ордера с виртуалки в реал.
  4. При такой схеме написание ТС - быстрое и понятное занятие. Перевод на реал (а это редкость на самом деле) делается всегда однообразно, быстро и четко.

речь идет о этом коде? https://www.mql5.com/ru/code/22770

понравилась реализация. действительно для тестера и оптимизатора самое то, наверно возьму за основу, код краткий и читаемый, если честно я удивлен, что Ваш код вот взял и прочитал, у Вас намного изощренней стиль написания, обычно тупо подключаю и юзаю, знаю, что не смогу логику понять

 
Igor Makanu:

увы, так делалось всегда, в МТ4 так и осталось Bid и Ask и никаких прихотей Создателя разрушить это простое использование и получение текущих цен ;)

Так ведь их значения неизменны в пределах текущей обработки события (если конечно принудительно не вызовешь RefreshRates).  Т.е. это именно переменные, а не функции.  А у вас функции выглядят как переменные

 

Дайте ФПшникам реальную задачу на управление и переработке массивов в сотни мегабайт или гигабайты данных, и вся их сказочная модель сообщений(данные неизменны) пойдет прахом.

Это теоретики, вовремя вырвавшиеся из реальных задач и вещающие в своей выдуманной вселенной :) рассказы про телеком - это тупейшие пассы данных.

По факту единственный шанс бороться со сложностью, это упаковка в обьекты.
 
Alexey Navoykov:

Так ведь их значения неизменны в пределах текущей обработки события (если конечно принудительно не вызовешь RefreshRates).  Т.е. это именно переменные, а не функции.  А у вас функции выглядят как переменные

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

я знаю, что сейчас на уровне процессора все кэшируется неоднократно, как и подозреваю, что разработчики компиляторов сделают более эффективным "вызов функции из вызова функции"

тогда Ваш пример должен выглядеть так:

#define Ask(dummy) SymbolInfoDouble(_Symbol,SYMBOL_ASK)
#define Bid(dummy) SymbolInfoDouble(_Symbol,SYMBOL_BID)

void OnStart()
  {
   Print("Ask = ",Ask());
   Print("Bid = ",Bid());
  }

или так:

#define Ask(symbol_) SymbolInfoDouble(symbol_,SYMBOL_ASK)
#define Bid(symbol_) SymbolInfoDouble(symbol_,SYMBOL_BID)

void OnStart()
  {
   Print("Ask = ",Ask(_Symbol));
   Print("Bid = ",Bid(_Symbol));
  }
 
Dmitry Fedoseev:

Василий, вот эта статья вам была бы очень полезна - что бы не мучить себя, выжимая их себя ООП ради ООП.

У меня есть идея функционального фреймворка для MT. Там ООП почти не будет. Только функции, "монады" и прочий псевдо ФП функционал. Пишу все в ковычках, т.к. естественно полноценный ФП в MQL не сделать.

 
Dmitry Fedoseev:

Комментарии излишни.

что вы так не любите друг друга, или может наоборот 2 гея ищут дорогу себе)

мне кстати понравились твои статьи, у Эксперта лоховские, слабые, но он мне не меньше нравится,

и я не гей.