Мой подход. Ядро - Движок. - страница 16

 
Реter Konow:

На данный момент, у меня один заказчик. Я очень быстро выполняю поставленные им задачи. 3-4 часа и новое, полностью функциональное окно готово. Вместе с интерфейсом подключения. Я также быстро исправляю баги движка и скидываю ему новые версии. 9 окон за несколько дней + изменения движка, исправление багов, добавление возможностей... Все очень быстро.

У вас наверно очень много свободного времени.

 
Vasiliy Sokolov:

Ну ты же понимаешь, что одного тебя мало. Массовость твоего движка будет зависеть от того, понравится ли он другим программистам (тебя же одного на всех заказчиков не хватит). А если прогерамм не понравится, то... увы и ах, судьба твоего творения будет беславной.

Программистам не нужно будет лезть в код движка. Они получат интерфейс подключения к нему в файле. Я уже протестировал это. Все работает.

 
Реter Konow:

На данный момент, у меня один заказчик. Я очень быстро выполняю поставленные им задачи. 3-4 часа и новое, полностью функциональное окно готово. Вместе с интерфейсом подключения. Я также быстро исправляю баги движка и скидываю ему новые версии. 9 окон за несколько дней + изменения движка, исправление багов, добавление возможностей... Все очень быстро.

Там правильно написано? 3-4 часа на создание окна? Не минут? 

 
Реter Konow:

Я уже более года это реально делаю. И не путаюсь.))

Для сравнение тоже самое реализуйте с использованием ООП. Попробуйте может вам понравится. :)

 
Dmitry Fedoseev:

Там правильно написано? 3-4 часа на создание окна? Не минут? 

Нет. Можно и за минуты, если скопировать код другого окна и внести изменения. Но, я говорил о создании с нуля, с продумыванием графики и работой над стилем.

 
Кстати, Peter, не забудьте добавить разного рода графики, вроде индикаторов, только в окошках, с поддержкой парочки форматов данных(OHLC, типа Зигзага, и др.). Надеюсь, что это всё легко реализуемо в вашем проекте.
 
Aliaksandr Hryshyn:
Кстати, Peter, не забудьте добавить разного рода графики, вроде индикаторов, только в окошках, с поддержкой парочки форматов данных(OHLC, типа Зигзага, и др.). Надеюсь, что это всё легко реализуемо в вашем проекте.

Постораюсь. 

 
Реter Konow:

Постораюсь. 

Не постараюсь, а сделаю). Увеличивает полезность вашего творения.

 
Dmitry Fedoseev:

Там правильно написано? 3-4 часа на создание окна? Не минут? 

бред какой то...сделать 3 окошка на MQL даже юзая библиотеки из стандартной поставки МТ работы на 10 минут и еще минут 20-30 на подгон по высоте и по XY кнопок, эдитов, лэйблев... 

вижу 2 варианта зачем работа Петра может пригодиться:

- создание отдельного приложения чтобы генерить исходники MQL, т.е.   GUI-конструктор и не вдаваться в подробности как оно крутится, так сказать Visual MQL++ )))

 - или: есть люди, которые сами создают себе трудности, а потом успешно их преодолевают © Уингстон Черчилль 

 

Мне кажется, все ООПпоненты Петера постоянно цепляются к частностям.

А суть вопроса - как раз в философии и архитектуре системы. 

Тут правильно выше говорили в чем спорные вопросы, представляющиеся Петеру преимуществами, а оппонентам - недостатками:

-  куча глобально доступных переменных, полное отсутствие инкапсуляции.  

- отсутствие контроля типов

- жёсткая заложенность на конкретную реализацию хранения данных. 

И Петер правильно сказал, что концепция ООП (по крайней мере в моих предложениях) предназначена для упрощения, "исходя из удобства программиста". Инкапсуляция, контроль типов, интерфейсы - все это призвано для того, чтобы как можно лучше исключить саму возможность ошибиться, перепутать, неправильно использовать. Все верно.

Концепция же Петера - противоположна. Все данные доступны отовсюду, пользователь из любой точки кода имеет полный контроль над всеми объектами программы, причем, воспринимать их он может так, как ему хочется, без всякого ограничения типов (ну, разве что с ограничениями самого MQL).

Петер утверждает, что такая концепция - позволяет "достичь максимального развития. Удобство на втором месте".

Лично мне, как программисту - уже то, что удобство на втором месте - не нравится. Но, этим можно пожертвовать, если реально мы получаем существенно большее развитие. Вот, хочется увидеть, в чем оно. Где ООП-подход с ограничениями и инкапсуляцией не позволяет достичь такого развития, как вот этот подход с полным доступом к громадному массиву свойств, скинутых в один массив чудовищных размеров. (Я уж не говорю о необходимости все это помнить). 

Верно тут выше замечено - подход напоминает паскалевский ТурбоВижн. Хотя, уже в этой библиотеке были заложены и контроль типов, и инкапсуляционные ограничения.