Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Код не переносимый, так в том и его особенность. Не предназначен он для перенесения. Другое у него предназначение. Ну а глобальная область переменных - мощный инструмент для работы сложных механизмов. Просто пользоваться нужно уметь. А когда мне говорят про какие то скрытые ошибки и баги, - я теряюсь. Не было у меня никогда никаких багов связанных с глобальной видимостью переменных. От слова совсем.
Проблема глобальных переменных в том, что, если проект достаточно большой и изменения состояния этих переменных происходит из многих участков кода, то достаточно трудозатратно искать баги.
Пример. Найден баг связанный с тем, что значение глобальной переменной явно не соответствует тому, которое должно быть. В проекте уже пару десятков файлов и 100500 строк кода. В скольких местах кода эта переменная меняется уже никто не помнит. Как результат - банка кофе и здоровый сон головой в клаву.
А теперь то же самое, но ООП. Мы же правильно написали код и все поля у нас private. Соответственно на прямую у нас он меняется только в методах класса, а из вне только методом Set. Соответственно вешаем точки останова на метод Set и, сколько у нас там методов в классе, где поле меняется, и спокойно отслеживаем откуда вносятся изменения и где поменяли неправильно.
Не было у меня никогда никаких багов связанных с глобальной видимостью переменных. От слова совсем.
даже не знаю как Вас убедить в очевидном, но наверное не стоит, мне же за это не платят?
Вы чего добиваетесь? ну если хотите чтобы Вас похвалили - держите:
Петр! Молодца, так держать!
))))
Проблема глобальных переменных в том, что, если проект достаточно большой и изменения состояния этих переменных происходит из многих участков кода, то достаточно трудозатратно искать баги.
Пример. Найден баг связанный с тем, что значение глобальной переменной явно не соответствует тому, которое должно быть. В проекте уже пару десятков файлов и 100500 строк кода. В скольких местах кода эта переменная меняется уже никто не помнит. Как результат - банка кофе и здоровый сон головой в клаву.
А теперь то же самое, но ООП. Мы же правильно написали код и все поля у нас private. Соответственно на прямую у нас он меняется только в методах класса, а из вне только методом Set. Соответственно вешаем точки останова на метод Set и, сколько у нас там методов в классе, где поле меняется, и спокойно отслеживаем откуда вносятся изменения и где поменяли неправильно.
даже не знаю как Вас убедить в очевидном, но наверное не стоит, мне же за это не платят?
Вы чего добиваетесь? ну если хотите чтобы Вас похвалили - держите:
Петр! Молодца, так держать!
))))
Ну может понимание того, что не только с ООП можно писать крутые проекты. И не только владение ООП - признак разработчика. Я же не спорю, что с ООП можно много задач решить. Но, есть и другие подходы.
дело не в ООП, а в самих принципах написания кода, я второй раз об этом и вот @Vladimir Simakov выше пример написал
использовать глобальную видимость переменных - да не вопрос, никто не запрещает, это можно делать - но по тихому, пока никто не видит! )))
но вот как постоянно используемый стиль написания программ это зло, причем чем больше кода, тем больше этого зла! - так обьяснил? )))
ЗЫ: еще один контрольный выстрел - посмотрите справку MQL, Вы видите что все функции выполнены отдельными законченными самостоятельными блоками? - передал параметры = получил результат! Вы считаете, что программисты Метаквот опять все делают не правильно? нужно использовать некие свободные стили написания функций - тут в глобальной видимости опишем, а вот тут юзер будет вызвать функцию и получит результат! )))) - процедурный стиль (когда каждая подпрограмма - законченный логический блок) это правильный код, пишите коды правильно! а не правильно ... ну оно само "когда нужно по быстрому" придет ;)
Из практики. У меня в проекте более 100 подключенных файлов. В некоторых более 2000 строк кода. Повсюду используются глобальные переменные. Никаких багов связанных именно с их глобальностью никогда не было. Может я просто приспособился?))
Просто у тебя очень хорошая память. Так везет не всем. Я вот уже слабо помню, какие переменные вводил сегодня. А какие неделю назад - вобще забыл. Но, это не проблема, все они локальны, а доступ к полям любого объекта идет только через соответствующие функции. Мне ООП позволяет не помнить многие моменты, я уже не раз говорил - в идеале, в любом месте кода тебе должно быть доступно только то, что необходимо, и ни одной переменной больше - так ты даже при желании не сможешь изменить то, что не следует. А когда тебе это реально потребуется, ты, чтобы получить доступ к переменной, должен будешь разобраться, почему у тебя нет доступа - это просто недосмотр, или, что случается куда чаще, данная переменная для модификации нуждается в дополнительных действиях. Если бы она была тебе сразу доступна, ты бы забыл про них, а потом бы долго разбирался почему программа не работает или работает не так как хочется.
Я ничего не добиваюсь. Ну может понимание того, что не только с ООП можно писать крутые проекты. И не только владение ООП - признак разработчика. Я же не спорю, что с ООП можно много задач решить. Но, есть и другие подходы.
Чем еще хорош ООП, так это тем, что потихоньку обрастаешь библиотеками классов, причем действительно универсальными, которые с тобой на всю жизнь и облегчают эту самую жизнь.
Из реального проекта, реально работает. Тут все без заморочек, просто надо контролировать, количество и состояние имеющихся ордеров/позиций. В этой функции только контроль того, что позиция/ордер не закрыты/отменены и удаление его из списка после закрытия.
, где gPos - это CList<CTrade> gPos
CList и CTrade не из стандартной библиотеки.
CTrade - наследует от моего же библиотечного CPosition.
Собственно ниже весь CTrade, который нужен только для обеспечения удобочитаемости кода проекта:
Вся реализация работы с ордерами/позициями скрыта в кросплатформенном библиотечном файле CPosition.Спасибо всем за участие в обсуждении. Я попробую вникнуть в ООП, чтобы по настоящему сравнить возможности двух подходов. Заинтересовала иерархия, которую может обеспечить ООП, и если польза от нее не будет погребена под его синтаксисом, непременно возьму на вооружение.
Ютуб в помощь. Там много чего. Особенно на английском, с которым ты дружишь.
Не пожалей, Петр, 45 минут. На начальном этапе очень важно понять, о чем этот товарищ толкует. Возможно многие с ним будут спорить, но в целом он прав:
Ютуб в помощь. Там много чего. Особенно на английском, с которым ты дружишь.
Не пожалей, Петр, 45 минут. На начальном этапе очень важно понять, о чем этот товарищ толкует. Возможно многие с ним будут спорить, но в целом он прав: