Структура рулит. Учимся структурировать программы, изучаем возможности, ошибки, решения и т.п. - страница 18
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ой, Владимир, не все так просто с твоей схемкой. Говоришь только драйвер переписать надо будет? А я вот насчитал гораздо больше платформозависимых частей:
Историю рынка как будешь получать, а историю торговли? А информацию о текущей позиции не из терминала случайно брать будешь? А если модуль волатильности внедрить придется - еще один платформозависимый API?
Адаптеры напишешь? И сколько их будет? Для истории рынка - один адаптер, для истории торговли - другой, для работы с позициями третий., в итоге модулей в два раза больше, а платформозависимого кода столько же.
Мне так видятся проблемы в другом.
Как раз всё что красное довольно стабильно, всё что идёт от платформы не меняется годами, если нужно под другую платформу то тоже есть устоявшийся API, переписать не проблема.
А вот все модули с зелёными стрелками свои, и почти всегда активной переделке (нет предела идеалу).
Прогнозатор направления написал, потом пришла новая идея углубить и расширить, ну типа сейчас то вообще то бай но нужно готовиться к селл, малпомалу сворачивать объём.
И давай курочить уже два модуля.
Корректор ММ тоже динамичная схема, сейчас работает с позой потом вдруг прозхрел и решил переделать на доливки (плавный вход в рынок).
С Драйвером рынка вроде должно быть стабильно тк он имеет выход на платформазависимый API, поэтому формализация чёткая, но накручено там будет мама не горюй тк API предоставляет кучу возможностей.
Мне так видятся проблемы в другом.
Как раз всё что красное довольно стабильно, всё что идёт от платформы не меняется годами, если нужно под другую платформу то тоже есть устоявшийся API, переписать не проблема.
Согласен. Только хочу ещё пояснить (пользуясь случаем) для Василия. Одна из важных идей отраженных в схеме не количество платформозависимых частей, а их строгая локализация. То есть: сама ТС (прогнозаторы + MM-модули) - это платформо-независимая конструкция, а источники данных индикаторы и драйвер рынка, соответственно зависимые (история торговли, подаваемая на вход корректора рекомендаций - это тоже по сути индикатор).
Следствие - чётко ограниченные зоны вмешательства однозначно различимые и непересекающиеся при
1. Миграции.
2. Совершенствовании ТС. В частности масштабировании.
А вот все модули с зелёными стрелками свои, и почти всегда активной переделке (нет предела идеалу).
Прогнозатор направления написал, потом пришла новая идея углубить и расширить, ну типа сейчас то вообще то бай но нужно готовиться к селл, малпомалу сворачивать объём.
И давай курочить уже два модуля.
Корректор ММ тоже динамичная схема, сейчас работает с позой потом вдруг прозхрел и решил переделать на доливки (плавный вход в рынок).
С Драйвером рынка вроде должно быть стабильно тк он имеет выход на платформазависимый API, поэтому формализация чёткая, но накручено там будет мама не горюй тк API предоставляет кучу возможностей.
Никто не обещал полное отсутствие сложностей. :) Но прикинь если все эти прямые API-вызовы ещё и не локализованы в драйвере, а перемешаны с кодами прогнозаторов и ММ-модулей.............
;)
Николай, твой пост весьма вменям, однако берусь поотстаивать предложенную схему (её универсальность).
Согласен. Только хочу ещё пояснить (пользуясь случаем) для Василия. Одна из важных идей отраженных в схеме не количество платформозависимых частей, а их строгая локализация. То есть: сама ТС (прогнозаторы + MM-модули) - это платформо-независимая конструкция, а источники данных индикаторы и драйвер рынка, соответственно зависимые (история торговли, подаваемая на вход корректора рекомендаций - это тоже по сути индикатор).
Следствие - чётко ограниченные зоны вмешательства однозначно различимые и непересекающиеся при
1. Миграции.
2. Совершенствовании ТС. В частности масштабировании.
Да само собой. Однако если при любых модификациях тщательно придерживаться разделения на плтформозависимые/независимые компоненты системы, то например в наших текущих реалиях можно с лёгкостью поддерживать разработку советников под обе платформы (MT4/5). Что при платформозависимых ТС вылилось бы в изрядный гемор.Модулей внутри выделенных на схеме компонент может быть сколько угодно. Это нормально. Мне представляется полезным только их чёткое конвейерное расположение. Которое не следует перемешивать внутри кода без абсолютно неизбежной необходимости. Т.е. следует избегать перемешивания, пока только возможно. Это позволяет всегда иметь четко определённые и удобные точки стыковки модулей при масштабировании в направлении мультиинструментальности. Посмотри на схему под этим углом, сам же это обнаружишь.
См. выше. // Зато вход корректора ММ - это удобнейшая точка интеграции тучи одновалютных (одноинструментальных точнее) прогнозаторов в многовалютную (мультиинструментальную) кухню.Никто не обещал полное отсутствие сложностей. :) Но прикинь если все эти прямые API-вызовы ещё и не локализованы в драйвере, а перемешаны с кодами прогнозаторов и ММ-модулей.............
;)
Ок, давай это возьмём за основу (только добавим модуль работы со стопами, вроде как резонно и ни у кого нет возражений),
и подумаем что в этой схеме ещё не хватает, или переделать.
Ок, давай это возьмём за основу (только добавим модуль работы со стопами, вроде как резонно и ни у кого нет возражений),
и подумаем что в этой схеме ещё не хватает, или переделать.
На счёт переделки-усовершенствования подумаю (пусть поварится).
С нехваткой очевиднее - в этой схеме явно не хватает GUI (подсистемы визуального мониторинга/управления). Хотелось бы для себя какую-нибудь унифицированную (и удобную!) схему взаимодействия советника с GUI разработать. Пока что у меня в этом вопросе царит стихийность, что меня сильно достаёт. Хотелось бы достичь той же задачи (полной абстракции данных в обоих направлениях). Эта проблема пока не решена. Потому и предлагал взять для тренировки задачу стыковки советника/GUI , меркантильный интерес присутствует, хотел идей поднасобирать от общественности.
Модулей внутри выделенных на схеме компонент может быть сколько угодно. Это нормально. Мне представляется полезным только их чёткое конвейерное расположение. Которое не следует перемешивать внутри кода без абсолютно неизбежной необходимости. Т.е. следует избегать перемешивания, пока только возможно. Это позволяет всегда иметь четко определённые и удобные точки стыковки модулей при масштабировании в направлении мультиинструментальности. Посмотри на схему под этим углом, сам же это обнаружишь.
Неограниченное разрастание модулей ведет к серьезным проблемам в будущем. У вас логика эксперта практически распыляется на разные модули. Сами модули будут взаимодействовать между собой, и нет гарантии что связи между ними не превратятся в запутанный клубок. Имхо, все квадратики помеченные зеленым цветом - элементы одной торговой системы. При их декомпозиции на разные модули нарушается один из главных принципов программирования: инкапсуляция данных и методов в рамках одной задачи.
Раз уж все начали свои схемки публиковать, я тоже продолжу. На этот раз еще более абстрактная схема:
Черными стрелочками описаны жесткие взаимосвязи. Серыми - приватные взаимосвязи внутри модуля, они не важны. Также класс торгового робота имеет право непосредственно обращаться к API платформы, но это снижает платформонезависимость.
Неограниченное разрастание модулей ведет к серьезным проблемам в будущем. У вас логика эксперта практически распыляется на разные модули. Сами модули будут взаимодействовать между собой, и нет гарантии что связи между ними не превратятся в запутанный клубок. Имхо, все квадратики помеченные зеленым цветом - элементы одной торговой системы. При их декомпозиции на разные модули нарушается один из главных принципов программирования: инкапсуляция данных и методов в рамках одной задачи.
Раз уж все начали свои схемки публиковать, я тоже продолжу. На этот раз еще более абстрактная схема:
Черными стрелочками описаны жесткие взаимосвязи. Серыми - приватные взаимосвязи внутри модуля, они не важны. Также класс торгового робота имеет право непосредственно обращаться к API платформы, но это снижает платформонезависимость.
На счёт переделки-усовершенствования подумаю (пусть поварится).
С нехваткой очевиднее - в этой схеме явно не хватает GUI (подсистемы визуального мониторинга/управления). Хотелось бы для себя какую-нибудь унифицированную (и удобную!) схему взаимодействия советника с GUI разработать. Пока что у меня в этом вопросе царит стихийность, что меня сильно достаёт. Хотелось бы достичь той же задачи (полной абстракции данных в обоих направлениях). Эта проблема пока не решена. Потому и предлагал взять для тренировки задачу стыковки советника/GUI , меркантильный интерес присутствует, хотел идей поднасобирать от общественности.
Иди от задачи. Какие задачи наиболее востребованы в GUI ? лично у тебя.
оттуда и пляши. Опиши что ты хочешь получить, выдели общие закидоны, сделай остов, потом добавь ещё кой чего, посмотри насколько легко изменяем остов.
Тогда придёт понимание каким он должен быть, перепиши всё заново. Мне видится как то так.
Все правильно говорит MetaDriver, и система у него правильная. Хрен_фх бы еще добавил, что "торговый драйвер" должен работать с 10-20 платформами для использования лучших цен.
Но использовать такую правильную систему удобно только в идеальных условиях - без ошибок в стратегии, без вмешательства пользователя, без форс-мажоров... А в реальности так бывает редко.
Разверну пример хрен_фх: работает 25 стратегий, агрегатор (торговый драйвер) их собирает в нетто-позицию и выводит в рынок, все ок. Вдруг в 17-й стратегии что-то ломается и она выдает нездоровые прогнозы - говорит открыться на 50% от депо. Советник послушно открывается.
Что делает банальный локер а-ля МТ4:
Теперь перейдем на "правильный учет". Что должен сделать трейдер, чтоб устранить ошибку (сделка на 50% маржи - явная ошибка в логике):
Вопрос: что проще? Очевидно, что вариант с МТ4.
А что дешевле? Очевидно, что вариант с Неттингом.
Какой вывод? Делать рыночный драйвер с GUI от МТ4 ;)
И еще в догонку.
Это все рассуждения от "правильных" трейдеров, да еще и программистов. Да, если для себя, любимого, да на счет с хорошим депозитом, то только так и надо.
А если затронуть экспертописательство, то получается, что это "правильно" ни кому не нужно. Толпы трейдунов-заказчиков не переделаешь, вот и приходится писать "для них".
Вариант "бросить работу" - принимается! =)
И еще в догонку.
Это все рассуждения от "правильных" трейдеров, да еще и программистов. Да, если для себя, любимого, да на счет с хорошим депозитом, то только так и надо.
А если затронуть экспертописательство, то получается, что это "правильно" ни кому не нужно. Толпы трейдунов-заказчиков не переделаешь, вот и приходится писать "для них".
Вариант "бросить работу" - принимается! =)