Мой подход. Ядро - Движок. - страница 139
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Что, народ, все убеждаете Петера в преимуществах ООП ?
Вот впустую ты бисер мечешь.
Правы вы ребята, знаю я все это и прекрасно понимаю. Но видать Петр затрагивает своим "не хочу, не буду" некие ментальные струнки моей ООП-души, вот и срываюсь постоянно в эти бесконечные объяснения споры и дрязги.
А движок будет загружать ядра из текстового файла. Это не сложно сделать.
А, ясно. Да, так лучше. Т.е. ядро у тебя это текстовой файл - по сути группа настроек для движка.
Нет, Василий, ты склонен все драматизировать.))
В конструкторе есть кнопка, при нажатии на которую печатаются все файлы.
А движок будет загружать ядра из текстового файла. Это не сложно сделать.
извините, что отвлекаю, но просто интересно - а как предполагается рефактор ? например поменять неудачные имена или вообще состав/расположение элементов
А, ясно. Да, так лучше. Т.е. ядро у тебя это текстовой файл - по сути группа настроек для движка.
Да. Именно так. Вся информация необходимая для движка, чтобы он воспроизвел конкретный GUI и работал с ним. Сейчас я устанавливаю ее напрямую в движок, а потом сделаю загружаемой из файла, который печатает конструктор.
извините, что отвлекаю, но просто интересно - а как предполагается рефактор ? например поменять неудачные имена или вообще состав/расположение элементов
Это все в конструкторе. Пишется KIB-код и перекомпилируется файл.
Вот как работать с конструктором https://www.mql5.com/ru/blogs/post/717782
Или еще пример. Недавно меня попросили подправить процедурный эксперт, так что бы он мог одновременно торговать на нескольких инструментах (запущенный на одном графике). В процедурном стиле пришлось бы куралесить очень долго и сложно, что бы заставить его независимо вести сделки на разных символах одновременно. Я же просто весь процедурный код разместил в классе и создал три его экзмемпляра. Каждому из которых указал индивидуальный набор настроек, включая рабочий символ и пр. Код заработал как надо с первого раза. Пользователь был доволен.
аналогичный пример у меня был на этой неделе, попросили сделать советник который по открытию бара на одном ТФ открывает покупки, а по открытию бара на другом ТФ открывает продажи, я даже сам не понял что меня сподвигло ))
но взял банальную ф-цию определения нового бара переписал в класс, и создал 2 экземпляра класса определения нового бара, при инициализации конструктора передавал в качестве параметра период ТФ
работы на 5 минут, но гарантированно все будет работать и не будет путаницы ни с именами ф-ций NewBar_TF1() , NewBar_TF2() .... как и удобно инициализировать после изменения настроек ТФ пользователем - удалил обьект в DeInit(), создал обьект в ONInit()
имхо, ООП это удобно и практично
Это все в конструкторе. Пишется KIB-код и перекомпилируется файл.
Вот как работать с конструктором https://www.mql5.com/ru/blogs/post/717782
Да. Именно так...
Вот поэтому много неразберихи с твоим движком у других и происходит. Даешь нестандартные имена элементам своей системы. Не ядро - а автогенерируемый файл настроек.
но оно же перетрёт все пользовательские правки-привязки которые в эвентах ?
Поясните подробнее.
Вот поэтому много неразберихи с твоим движком у других и происходит. Даешь нестандартные имена элементам своей системы. Не ядро - а автогенерируемый файл настроек.
Так файл, - это напечатанные ядра. Там их несколько.