Пользовательская ТС средствами MQL - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Да все так же, как в визуальных конструкторах. Проблема вовсе не в том, что это невозможно. А в том, что этим невозможно будет пользоваться.
Проблема в том, что это очень сложно в реализации. А пользоваться будет на много проще, чем проверять торговые системы вручную или писать советники не посвященному в программирование трейдеру.
Подозреваю, что для тебя, как титана запоминания - возможно, смысл очень даже есть.
Там суть такая, что уже при десятке блоков - воспринимать структуру эксперта становится непросто. Реальный же эксперт - включает, как правило, гораздо больше. Еще наворотить такую схему связей можно. А вот исправить случайную ошибку - становится крайне проблематично.
Это - как раз к недавнему вопросу об ограничении доступа. Такая "блочная схема" - предоставляет тебе СРАЗУ ВЕСЬ доступ ко всем элементам. И трудность поддержки - как раз и заключается в том, что тебе приходится держать в голове большую часть всех этих связей. Большинство же людей, как правило, способна комфортно удерживать в кратковременной памяти пять-семь сущностей. Визуальный конструктор тем и хорош, что вначале - он тебе предоставляет доступ ко всему небольшому количеству блоков системы, но этим же и плох, что в конце, когда блоков становится слишком много - он тебе предоставляет доступ сразу ко всем.
Данная проблема как раз и решается с помощью инкапсуляции - введения локальных переменных, виртуализации, пространства имен, и прочего. Цель - добиться, чтобы в каждом месте системы был доступ исключительно только к тому, что необходимо в данный момент, с минимальными правами, которые необходимы в данный момент.
Ок. Теперь ясно.
Но согласись, - сложность запоминания большого количества взаимосвязей между блоками структуры является инвариантной и никуда не исчезает при любом методе построения структуры (имею ввиду структуру как таковую в широком смысле). Стоит ли приносить эффективность самой структуры в угоду легкости ее запоминания (это к вопросу о необходимости ООП)? Может лучше оптимизировать призму своего взгляда на структуру, чтобы запоминать ее легче? Не является ли проблема с запоминанием сложных структур, проблемой неоптимизированности именно памяти человека, а не структуры? Например: лист бессмысленно составленного текста из случайного набора слов, с ходу не сможет запомнить почти никто, но стоит человеку найти в тексте смысл (даже если его там на самом деле нет), как он не обладая супер-памятью, сможет воспроизвести немалую часть его содержания.
Насчет явной инкапсуляции (под неявной я подразумеваю ту, что существует в сознании разработчика), которая присутствует в ООП, - так она тоже может быть реализована в "блочном" конструкторе. Можно подумать как ее реализовать. Ты же знаешь, что человек намного лучше воспринимает образы, чем слова и тем более цифры. Особенно, если они на чужом языке обличены в непонятные сущности, понимание которых требует долгого обучения.
Можете в качестве отправной точки посмотреть на эксперт из кодебазы: exp_iCustom,
Или в моей статье есть похожий фреймворк для подключения разных индюков и торговли по ним.
Принцип ясен. Спасибо, Станислав!
Проблема в том, что это очень сложно в реализации. А пользоваться будет на много проще, чем проверять торговые системы вручную или писать советники не посвященному в программирование трейдеру.
Да ты сперва попробуй. Возьми TSLab, да попробуй запрограммировать в визуальном виде хотя бы одного эксперта средней сложности.
Пока мы имеем дело с переворотами на пересечении цены и скользящей - это делается быстро, легко, и визуальное представление получается очень даже приятным.
Но уже если надо прикрутить к этому советнику фильтр на вход, плюс трейлинг, плюс простейший мартингейл (который жутко любят новички) - уже начинаются проблемы. Набрать эти блоки можно. Соединить их можно. Но вот дальше - трудности.
А "сложность в реализации" - это фигня. "Осел, груженный золотом - пробивает ворота любой крепости" (С). Сделать все можно. Но какой в этом смысл ?
Ок. Теперь ясно.
Но согласись, - сложность запоминания большого количества взаимосвязей между блоками структуры является инвариантной и никуда не исчезает при любом методе построения структуры (имею ввиду структуру как таковую в широком смысле). Стоит ли приносить эффективность самой структуры в угоду легкости ее запоминания (это к вопросу о необходимости ООП)? Может лучше оптимизировать призму своего взгляда на структуру, чтобы запоминать ее легче? Не является ли проблема с запоминанием сложных структур, проблемой неоптимизированности именно памяти человека, а не структуры? Например: лист бессмысленно составленного текста из случайного набора слов, с ходу не сможет запомнить почти никто, но стоит человеку найти в тексте смысл (даже если его там на самом деле нет), как он не обладая супер-памятью, сможет воспроизвести немалую часть его содержания.
Насчет явной инкапсуляции (под неявной я подразумеваю ту, что существует в сознании разработчика), которая присутствует в ООП, - так она тоже может быть реализована в "блочном" конструкторе. Можно подумать как ее реализовать. Ты же знаешь, что человек намного лучше воспринимает образы, чем слова и тем более цифры. Особенно, если они на чужом языке обличены в непонятные сущности, понимание которых требует долгого обучения.
Так в том же и задача программиста - чтобы писать программу, не запоминая сложные связи между объектами ! Чтобы не надо было все запоминать !
Все верно ты написал. У тебя инкапсуляция тоже есть, она в сознании. Когда ты работаешь с каким-то блоком - ты ж не думаешь о всех доступных тебе возможностях !
Ну, вот, я - сторонник того, чтобы это реализовывалось средствами самого языка и компилятора.
Система же, которую хочет реализовать Михаил - она изначально предлагает пользователю доступ ко ВСЕЙ архитектуре. Я неоднократно пытался работать с подобными конструкторами - неоднократно убеждался, что пока система невелика - такой визуальный конструктор куда удобнее описательного подхода языков программирования. Однако, по мере разрастания системы - неизбежно приходит момент, когда "за деревьями не видно леса" - мешанина визуальных блоков и их связей перестает восприниматься. И неизбежно приходится переходить к инкапсуляции на описательном уровне. И следующий шаг в этом направлении - виртуализация, когда в каждой точке программы доступно очень мало сущностей, и причем, не напрямую, а через стандартизированный протокол-интерфейс, через который пользователь никак не может иметь доступ к чему-то, сверх предоставленного.
Всё уже давно реализовано и называется MQL Wizard. Если не хватает каких либо модулей то их можно написать самому и потом использовать в других наработках.