Структура рулит. Учимся структурировать программы, изучаем возможности, ошибки, решения и т.п. - страница 10
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я не понаслышке знаком с State программированием и сам использовал его несколько лет. Однако через некоторое время использования этой методы я принял решение отказаться от нее и разработал на ее основе более прозрачную, более простую и более подходящую модель для трейдинга.
Внимательно читаем вот эту статью: Автоматное программирование как новый способ создания автоматических торговых систем
Потом внимательно читаем вот эти комментарии к ней.
Затем очень, очень проникновенно созерцаем одну невзрачную табличку из статьи, и думаем, что бы она могла значить:
Если после всего прочитанного у вас по-прежнему нечто вроде "Вау! State-программирование это так круто!" - что же, так и считайте.
От себя добавлю что основной проблемой State программирования являются ситуации, которые плодят массу бесполезных режимов (смотрим графу N State). В State программировании, каждый режим должен описывать свои правила отдельно. Поясню на примере, допустим мы находимся в режиме Buy. И все хорошо, пока робот не решает открыть еще одну позицию. А в самом деле, почему бы и нет? Условия выхода из старой позиции не соблюдены, и закрывать ее еще рано, а новый сигнал пропускать нельзя. И вот здесь начинаются проблемы, потому что в момент поступления нового сигнала робот находится в режиме Buy, а правила открытия новой позиции находятся в режиме State (ожидание и поиск новых сигналов на вход). Теперь уже в режиме Buy приходится заново описывать те же правила открытия позиции что и в режиме State. А если новая позиция противоположена по направлению (хедж)? Такая позиция открывается, а что с ней делать дальше? Ведь ее логика сопровождения описана в режиме Sell, а робот находится в режиме Buy. Можно просто перейти в режим Sell, но что делать с оставшейся позицией Buy? В общим, на этот случай приходится писать еще один бесполезный режим вроде BuyAndSell. Избыточность режимов плодит еще одну ситуацию: одно и тоже действие совершают разные участки кода. В общем для любителей экспоненциального гемороя state программирование самое то.
"Вот оно как Михалыч" (с)... И я вот тоже прозрачненько на это намекаю.
(fcplm)
Да нифига.
Вот тут подумалось, что если бы MQL5 поддерживал множественное наследование, а также класс мог бы объявлять абстрактные методы - это открыло бы путь к использованию интерфейсов что было бы очень здорово для больших проектов.
Абстрактные методы прямо не запрещены (я частенько использую альтернативную нотацию),
а множественное наследование - это огромным плюсом было бы.
Абстрактные методы прямо не запрещены, а множественное наследование - это огромным плюсом было бы.
Говоря цитатой приведённой Rosh: как это поможет вам пилить дрова?
Вон FAQ сидит на четвёре и в вус не дует, и ни какие абстрактные методы и множественное наследование ему не упирается.
Хоть будут абстрактные методы, хоть нет, всё равно это не снимет задачу структурирования проекта.
Кстати чем больше вариантов реализации одной и той же задачи тем сложнее сделать выбор какой из вариантов применить.
Получается что программист часто сваливается в задачу красоты кода. Такое себе искусство ради искусства.
ЗЫ а вообше (говоря за себя) я замечаю что чем больше штампов построения (планирования) проекта, тем проще.
Потом можно изменить, доизменить, переизменить, передоизменить,
но первоначальный каркас (пусть и не ахти какой) задаёт тон всего построения.
Говоря цитатой приведённой Rosh: как это поможет вам пилить дрова?
Потом можно изменить, доизменить, переизменить, передоизменить,
но первоначальный каркас (пусть и не ахти какой) задаёт тон всего построения.
Скорость пилки дров возрастёт.
Если уже есть четкое представление как и что должно выглядеть - то наверное можно и на MQL4 всё сделать по уму.
А если такого представления нет - то значит будет куча изменений и дополнений. И множественное наследование в частности позволяет вносить изменения с минимальными издержками.
С абстрактными методами согласен - просто красивая форма записи.
Скорость пилки дров возрастёт.
Если уже есть четкое представление как и что должно выглядеть - то наверное можно и на MQL4 всё сделать по уму.
А если такого представления нет - то значит будет куча изменений и дополнений. И множественное наследование в частности позволяет вносить изменения с минимальными издержками.
Сейчас от наследования стараются отказываться в пользу включения. Представляете, какое отношение должно быть к множественному наследованию?
FAQ:
Да нифига.
Еще как фига. Использовать switch... case и использовать паттерн state machine это две разных вещи. По тексту видно, что паттерном там и не пахло, как и в приведенной статье.
Читается примерно как "я изобрел уникальную выигрышную систему..." и дальше кривое изложение мартина.