Мт4 Конец поддержке. - страница 28
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Не знаю, предлагал ли кто, но почему бы все что есть в MT4 не перенести в MT5, тогда бы все перешли.
George Merts:
Сперва пишут части, а потом объединяют их в целое, нередко сталкиваясь с тем, что части плохо совместимы друг с другом - кстати, как раз этим объясняется желание "иметь доступ ко всем имеющимся переменным".
Да нет же. Не идет речи о доступе ко всем возможным переменным, а только к тем которые нужны. Обычно это входные и выходные переменные разных функций.
Добавление сюда добавочных границ сразу значительно усложнит читаемость кода и увеличит возможные ошибки когда что-то куда-то не дошло ибо потерялось по дороге из-за этих границ.
Конечно понятно желание хоть как-то притянуть зауши ООП хоть для чего-то полезного, но такие случаи обычно лежат не в сфере программирования, а в комерческой сфере, например накрутка добавочных часов программирования, разведения бесконечных дискуссиий об архитектуре интерфейсов и тому подобного приятного времяпровождения в рабочее время.
А в принципе такой пример есть? Пусть не Ваш? У меня есть глубокие сомнения. В начале двухтысячных я перестал подсчитывать количество написанных мной отлаженных и работающих строк программного кода потому, что оно превысило миллион, стало неинтересно. И ни разу не встречалась необходимость создавать свой класс, хотя разнообразие и масштабы задач были самыми разными. Переменные процедурного типа использовать приходилось, когда надо было распараллелить работу на несколько человек, но не более. Почему так?
Дело в том что ООП может быть применимо только к упаковке готового кода, на стадии написания кода оно лишь мешает. Но если такой необходимости нет то и ООП не нужно.
Vladimir:
Выходит, ООП препятствует автоматическому распараллеливанию вычислений. Сейчас уже следует считать это очень серъезным недостатком, перспектива не за ООП.
Перспектива в языках типа Systemverilog.
Все ничего, если не считать, что функции isNewBar() вообще в природе быть не должно. Забавно, что вокруг такой мелочи столько танцев.
Просто переменная, и просто она сравнивается со временем бара, если все дела прошли успешно, то переменной в конце присваивается время нового бара. Иначе на все дела выделяется только одна попытка.
Добавление сюда добавочных границ сразу значительно усложнит читаемость кода и увеличит возможные ошибки когда что-то куда-то не дошло ибо потерялось по дороге из-за этих границ.
Как раз все наоборот - границы позволяют не думать о том, "а зачем вот эта переменная, какую роль она играет в данном случае, не следует ли ее учесть ?"
Пользователь имеет доступ только к тому, что ему необходимо учитывать, и только к тому, что ему можно изменять. Вот те самые ошибки "когда что-то потерялось по дороге" - и возникают именно из-за того, что доступно слишком много, и что-то "забыли по пути". С "усеченными" виртуальными интерейсами это сделать куда труднее.
Вот простейший пример: получение позиции. Позиция - это либо открытые ордера в МТ4, либо открытые позиции в МТ5.
Если у тебя полный доступ, то при выборе позиции - пользователю надо помнить, какие переменные сейчас можно читать, какие переменные в данный момент невалидные, какие переменные он может поменять, какие нет.
С интерфейсом - все куда проще. Ты его получил, а в нем - лишь две функции: получить число компонент, и получить указатель на константную компоненту. ВСЕ. С помощью этих двух функций - ты физически не можешь получить доступ ни к каким "лишним переменным".
Andrei:
Конечно понятно желание хоть как-то притянуть зауши ООП хоть для чего-то полезного, но такие случаи обычно лежат не в сфере программирования, а в комерческой сфере, например накрутка добавочных часов программирования, разведения бесконечных дискуссиий об архитектуре интерфейсов и тому подобного приятного времяпровождения в рабочее время.
А к этому - ты сам придешь рано или поздно. Причем, инкапсуляцию-то можно сделать и в "чисто процедурном" подходе. Но, в ООП-подходе это удобнее, поскольку еще "автоматом" ты получаешь наследование и полиморфизм.
Не знаю, предлагал ли кто, но почему бы все что есть в MT4 не перенести в MT5, тогда бы все перешли.
Проблема далеко не только в том, что в 4-ке есть что-то, чего нет в 5-ке. И даже не в ООП.
5-ка практически ничего не дала трейдерам (не программиста, не трейдерам-программистам - просто трейдерам).
Свой формат истории, запрет кастомной - да только эти два пункта отпугнули всех, кто торгует геометрию. И никакие "много ТФ" (при этом без годового, lol), масштабы в пунктах на бар их не привлекут.
Простой вопрос. Что показывает "сетка"? Попытки выяснить приведут вас к рекомендации обратиться о фриланс и заказать какую хотите.
МТ - терминалы для программистов. В этом весь ответ.
Дело в том что ООП может быть применимо только к упаковке готового кода, на стадии написания кода оно лишь мешает. Но если такой необходимости нет то и ООП не нужно.
Да нет. Все наоборот.
Интерфейсы взаимодействия - определяются изначально, еще "до стадии написания кода". Интерфейсы - это, по сути - все тоже ТЗ для программиста. Все взаимодействия во Фрилансе проводятся именно с использованием четкого ТЗ. Вот, виртуальные интерфейсы - это и есть своего рода ТЗ, с которого и начинается программирование.
Ты просто, как я понял, неверно подходишь к самой сути ООП. Ты сперва пишешь кучу функций, а потом - приходится "втискивать" их в ООП-оформление. Но это - неверный путь. Правильно делать наоборот - сперва определяется ООП-оформление, те самые наборы базовых интерфейсов между компонентами системы. А потом - последовательно пишется каждая компонента, придерживаясь вот этих самых, заранее определенных интерфейсов.
Да, бывает так, что при написании выясняется, что интерфейс чего-то не предусмотрел. И начинается... "Воооот... в процедурном подходе - у меня был бы доступ ко всему этому я бы без проблем сделал то, что надо, а теперь - как я к этим переменным получу доступ ?". Это случается, когда на стадии проектирования интерфейсов - чего-то не учли. И это очень неприятная ситуация - приходится либо добавлять какие-то дополнительные интерфейсы, либо менять существующие - что чревато ошибками. Такой ситуации, надо, конечно, стараться избегать.
Вот простейший пример: получение позиции. Позиция - это либо открытые ордера в МТ4, либо открытые позиции в МТ5.
Если у тебя полный доступ, то при выборе позиции - пользователю надо помнить, какие переменные сейчас можно читать, какие переменные в данный момент невалидные, какие переменные он может поменять, какие нет.
С интерфейсом - все куда проще. Ты его получил, а в нем - лишь две функции: получить число компонент, и получить указатель на константную компоненту. ВСЕ. С помощью этих двух функций - ты физически не можешь получить доступ ни к каким "лишним переменным".
Как раз все обстоит наоборот. Пользователям часто важно знание внутренних переменных для качественного тестирования модулей например, а этого нет. И придумываются специальные хитрые способы как этот доступ потом получить. Так что лишней информации не бывает в принципе, а кому она не нужна могут просто ею не пользоваться.
Как раз все обстоит наоборот. Пользователям часто важно знание внутренних переменных для качественного тестирования модулей например, а этого нет. И придумываются специальные хитрые способы как этот доступ потом получить. Так что лишней информации не бывает в принципе, а кому она не нужна могут просто ею не пользоваться.
Если требуется "хитрый доступ для получения" - это говорит о неверном проектировании системы.
Например, если мы пишем генератор входных сигналов - нам не должна быть доступна информация, касающаяся, скажем, манименеджмента.
Конечно, при отладке может возникнуть, допустим, ситуация, когда не состоялся вход - надо сразу отсеять ситуацию, когда это произошло потому, что манименеджмент запретил операцию (скажем, маржи не хватает). А как ты узнаешь об этом из генератора входов ? Никак - у тебя нет доступа. Но, в данном случае - достаточно убедиться, что генератор-то выставил сигнал на вход, и сработал правильно. Входа же не было - по какой-то другой причине, которая лежит вне генератора входов. Выяснение причины при этом - действительно, несколько сложнее, чем если бы мы прямо имели доступ ко всем переменным манименеджмента. Но, гораздо опаснее, что при обычной, штатной работе - мы, имея к ним доступ - "влезем не туда".
Если требуется "хитрый доступ для получения" - это говорит о неверном проектировании системы.
Разработка в первую очередь естественный процесс ума.
В этом процессе идеи, формируются свободно и даже стихийно.
Следование ООП усложняет свободную трансформации кода.
В естественном процессе развития, код сам постепенно сжимается и универсализуется.
В естественном процессе функции не дробятся, а наоборот растут и объединяются в большие блоки.
Большие блоки решают широкий спектр задач.
ООП мешает формированию таких блоков, оставляя код раздробленным.
ООП создает усложненный доступ, из за чего количество ссылок на переменные неуклонно растет.
Преимущества разграничения доступа перекрываются трудностью сделать цельный механизм.
Главный минус: ООП заставляет идти по пути дробления кода на множество функций.
Для человека легче воспринимать раздробленный код, но раздробленность противопоказана любому механизму.