Мой подход. Ядро - Движок. - страница 16
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
На данный момент, у меня один заказчик. Я очень быстро выполняю поставленные им задачи. 3-4 часа и новое, полностью функциональное окно готово. Вместе с интерфейсом подключения. Я также быстро исправляю баги движка и скидываю ему новые версии. 9 окон за несколько дней + изменения движка, исправление багов, добавление возможностей... Все очень быстро.
У вас наверно очень много свободного времени.
Ну ты же понимаешь, что одного тебя мало. Массовость твоего движка будет зависеть от того, понравится ли он другим программистам (тебя же одного на всех заказчиков не хватит). А если прогерамм не понравится, то... увы и ах, судьба твоего творения будет беславной.
Программистам не нужно будет лезть в код движка. Они получат интерфейс подключения к нему в файле. Я уже протестировал это. Все работает.
На данный момент, у меня один заказчик. Я очень быстро выполняю поставленные им задачи. 3-4 часа и новое, полностью функциональное окно готово. Вместе с интерфейсом подключения. Я также быстро исправляю баги движка и скидываю ему новые версии. 9 окон за несколько дней + изменения движка, исправление багов, добавление возможностей... Все очень быстро.
Там правильно написано? 3-4 часа на создание окна? Не минут?
Я уже более года это реально делаю. И не путаюсь.))
Для сравнение тоже самое реализуйте с использованием ООП. Попробуйте может вам понравится. :)
Там правильно написано? 3-4 часа на создание окна? Не минут?
Нет. Можно и за минуты, если скопировать код другого окна и внести изменения. Но, я говорил о создании с нуля, с продумыванием графики и работой над стилем.
Кстати, Peter, не забудьте добавить разного рода графики, вроде индикаторов, только в окошках, с поддержкой парочки форматов данных(OHLC, типа Зигзага, и др.). Надеюсь, что это всё легко реализуемо в вашем проекте.
Постораюсь.
Постораюсь.
Не постараюсь, а сделаю). Увеличивает полезность вашего творения.
Там правильно написано? 3-4 часа на создание окна? Не минут?
бред какой то...сделать 3 окошка на MQL даже юзая библиотеки из стандартной поставки МТ работы на 10 минут и еще минут 20-30 на подгон по высоте и по XY кнопок, эдитов, лэйблев...
вижу 2 варианта зачем работа Петра может пригодиться:
- создание отдельного приложения чтобы генерить исходники MQL, т.е. GUI-конструктор и не вдаваться в подробности как оно крутится, так сказать Visual MQL++ )))
- или: есть люди, которые сами создают себе трудности, а потом успешно их преодолевают © Уингстон Черчилль
Мне кажется, все ООПпоненты Петера постоянно цепляются к частностям.
А суть вопроса - как раз в философии и архитектуре системы.
Тут правильно выше говорили в чем спорные вопросы, представляющиеся Петеру преимуществами, а оппонентам - недостатками:
- куча глобально доступных переменных, полное отсутствие инкапсуляции.
- отсутствие контроля типов
- жёсткая заложенность на конкретную реализацию хранения данных.
И Петер правильно сказал, что концепция ООП (по крайней мере в моих предложениях) предназначена для упрощения, "исходя из удобства программиста". Инкапсуляция, контроль типов, интерфейсы - все это призвано для того, чтобы как можно лучше исключить саму возможность ошибиться, перепутать, неправильно использовать. Все верно.
Концепция же Петера - противоположна. Все данные доступны отовсюду, пользователь из любой точки кода имеет полный контроль над всеми объектами программы, причем, воспринимать их он может так, как ему хочется, без всякого ограничения типов (ну, разве что с ограничениями самого MQL).
Петер утверждает, что такая концепция - позволяет "достичь максимального развития. Удобство на втором месте".
Лично мне, как программисту - уже то, что удобство на втором месте - не нравится. Но, этим можно пожертвовать, если реально мы получаем существенно большее развитие. Вот, хочется увидеть, в чем оно. Где ООП-подход с ограничениями и инкапсуляцией не позволяет достичь такого развития, как вот этот подход с полным доступом к громадному массиву свойств, скинутых в один массив чудовищных размеров. (Я уж не говорю о необходимости все это помнить).
Верно тут выше замечено - подход напоминает паскалевский ТурбоВижн. Хотя, уже в этой библиотеке были заложены и контроль типов, и инкапсуляционные ограничения.