Рекорд на Маркете - страница 31
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Наверное потому, что я работаю не в компании. И мне легче использовать процедурное программирование, а не ООП.
на этот счет было много споров конечно.
Ну, вот, как раз, в последнюю неделю занимался тем, что немного модифицировал алгоритм оценки качества торговли для своей Лиги ТС. И очень порадовался, что у меня все построено на виртуальных интерфейсах.
Суть в том, что раньше максимальный просад оценивался исключительно по балансу. А мне захотелось расчитывать его по Эквити. Но для этого, при анализе истории - для каждой сделки надо запросить таймсерии, и посмотреть, какой максимальный просад в сделке был, исходя из тогдашних цен.
А теперь учти, что у меня код переносимый, то есть на основе одного и того же интерфейса - работает как МТ4, так и МТ5. Соответственно, для каждой платформы - вызывается соответствующий класс, со своими функциями, которые заметно отличаются. И вот, пока я дорабатывал код - наверно, с десяток раз была ситуация, когда я не мог напрямую обратиться к нужным данным - интерфейсы этого не позволяли. И каждый раз я убеждался, что все правильно, что интерфейсы меня ограничили - если бы я "влез" в эти данные прямо - это привело бы к ошибкам в других частях программы. К нужным же мне данным - я должен был обратиться иначе, через дополнительные запросы, что позволило быть уверенным, что никакие другие части не задеты.
Резюмируя: очередной раз убедился, что принцип "в каждом месте пользователю должны быть доступны только те структуры, которые ему необходимы сейчас, и больше - никакие" - совершенно верен. Нельзя допускать, чтобы пользователю всегда было доступно все, что угодно - это чревато внесением ошибок при модификации.
Но, с другой стороны - люди, которые привыкли к процедурному стилю - просто сами себя ограничивают в таких случаях, помня, какие данные можно менять из данного места, а какие нельзя.
Ну, вот, как раз, в последнюю неделю занимался тем, что немного модифицировал алгоритм оценки качества торговли для своей Лиги ТС. И очень порадовался, что у меня все построено на виртуальных интерфейсах.
Суть в том, что раньше максимальный просад оценивался исключительно по балансу. А мне захотелось расчитывать его по Эквити. Но для этого, при анализе истории - для каждой сделки надо запросить таймсерии, и посмотреть, какой максимальный просад в сделке был, исходя из тогдашних цен.
А теперь учти, что у меня код переносимый, то есть на основе одного и того же интерфейса - работает как МТ4, так и МТ5. Соответственно, для каждой платформы - вызывается соответствующий класс, со своими функциями, которые заметно отличаются. И вот, пока я дорабатывал код - наверно, с десяток раз была ситуация, когда я не мог напрямую обратиться к нужным данным - интерфейсы этого не позволяли. И каждый раз я убеждался, что все правильно, что интерфейсы меня ограничили - если бы я "влез" в эти данные прямо - это привело бы к ошибкам в других частях программы. К нужным же мне данным - я должен был обратиться иначе, через дополнительные запросы, что позволило быть уверенным, что никакие другие части не задеты.
Резюмируя: очередной раз убедился, что принцип "в каждом месте пользователю должны быть доступны только те структуры, которые ему необходимы сейчас, и больше - никакие" - совершенно верен. Нельзя допускать, чтобы пользователю всегда было доступно все, что угодно - это чревато внесением ошибок при модификации.
Но, с другой стороны - люди, которые привыкли к процедурному стилю - просто сами себя ограничивают в таких случаях, помня, какие данные можно менять из данного места, а какие нельзя.
Ну, это и есть конкуренция. Ничего не поделаешь. Только сдаваться не нужно. Продолжайте двигаться вперед и победите. Иначе, останетесь позади.
Насчет ООП, - забудьте. Если этот вопрос Вас донимает, то скажу, что в программировании нужно использовать только то, без чего не обойтись. Если Вы можете обойтись процедурным стилем, - так и работайте.
Мой принцип: "Если в решении задачи можно без чего то обойтись, то без этого определеннно следует обойтись".
А нужна ли собаке пятая нога? :)
Именно.
Такая конкуренция и нужна.
Вы удивитесь, но я до сих пор страдаю процедурным программированием.
Вот как влился в 14 лет в Паскаль и не могу поменять себя. И классы уже давно "выучил", но не могу себя переубедить...
Наверное потому, что я работаю не в компании. И мне легче использовать процедурное программирование, а не ООП.
принципы ООП мало чем отличаются от процедурного программирования, тем более в MQL-программах задачи решаются узкоспециализированные и часто нет смысла разрабатывать внутреннюю структуру класса. В кодобазе более 90% примеров с использованием классов это не более чем "обернутое в класс" процедурное программирование, т.к. задачи которые решает класс выполняются разово и не используются наследование и полиморфизм (т.к. нет необходимости).
А серьезные задачи где без ООП никак - это графика, эту задачу уже выполнили и она в свободном доступе и нужно просто этим (графика в MQL) уметь пользоваться или модифицировать ( как и применять наследование) .
ЗЫ Стандартная поставка МТ в стиле ООП, очень радует, все готово и минимум модификаций - задача, лишь научиться этим пользоваться, а откуда вызвать из своего класса или из своих "подпрограмм", имхо, дело вкуса.
ЗЫЗЫ: вот чего про удобство не скажу в части использования ALGLIB - его бы точно нужно в нормальный класс "обернуть"!
Igor Makanu:
...
А серьезные задачи где без ООП никак - это графика...
Очень спорно.))
Очень спорно.))
принципы ООП мало чем отличаются от процедурного программирования, тем более в MQL-программах задачи решаются узкоспециализированные и часто нет смысла разрабатывать внутреннюю структуру класса. В кодобазе более 90% примеров с использованием классов это не более чем "обернутое в класс" процедурное программирование, т.к. задачи которые решает класс выполняются разово и не используются наследование и полиморфизм (т.к. нет необходимости).
А серьезные задачи где без ООП никак - это графика, эту задачу уже выполнили и она в свободном доступе и нужно просто этим (графика в MQL) уметь пользоваться или модифицировать ( как и применять наследование) .
ЗЫ Стандартная поставка МТ в стиле ООП, очень радует, все готово и минимум модификаций - задача, лишь научиться этим пользоваться, а откуда вызвать из своего класса или из своих "подпрограмм", имхо, дело вкуса.
ЗЫЗЫ: вот чего про удобство не скажу в части использования ALGLIB - его бы точно нужно в нормальный класс "обернуть"!
Смотря для чего.
Для простоты пользования другими пользователями?
Возможно и да.
Для того, чтобы у пользователей не было желания "полазить" и навредить.
Я для своей графики использую 5 функций рисования (текст, кнопка, ЧекБокс, поле, фон) ! все :-)
Для меня все понятно. Другим и не нужно этого видеть.
Именно.
Такая конкуренция и нужна.
Я мечтаю, чтобы такая конкуренция росла у нас в Маркете. Только Маркет нужно в порядок привести.
Чтобы соверноваться в плавании, нужно бассейн сначала почистить, и потом залить водой. Короче, условия подходящие нужны.
Будет в бассейне грязно, никто соревноваться не захочет. :)Ну, вот, как раз, в последнюю неделю занимался тем, что немного модифицировал алгоритм оценки качества торговли для своей Лиги ТС. И очень порадовался, что у меня все построено на виртуальных интерфейсах.
Суть в том, что раньше максимальный просад оценивался исключительно по балансу. А мне захотелось расчитывать его по Эквити. Но для этого, при анализе истории - для каждой сделки надо запросить таймсерии, и посмотреть, какой максимальный просад в сделке был, исходя из тогдашних цен.
А теперь учти, что у меня код переносимый, то есть на основе одного и того же интерфейса - работает как МТ4, так и МТ5. Соответственно, для каждой платформы - вызывается соответствующий класс, со своими функциями, которые заметно отличаются. И вот, пока я дорабатывал код - наверно, с десяток раз была ситуация, когда я не мог напрямую обратиться к нужным данным - интерфейсы этого не позволяли. И каждый раз я убеждался, что все правильно, что интерфейсы меня ограничили - если бы я "влез" в эти данные прямо - это привело бы к ошибкам в других частях программы. К нужным же мне данным - я должен был обратиться иначе, через дополнительные запросы, что позволило быть уверенным, что никакие другие части не задеты.
Резюмируя: очередной раз убедился, что принцип "в каждом месте пользователю должны быть доступны только те структуры, которые ему необходимы сейчас, и больше - никакие" - совершенно верен. Нельзя допускать, чтобы пользователю всегда было доступно все, что угодно - это чревато внесением ошибок при модификации.
Но, с другой стороны - люди, которые привыкли к процедурному стилю - просто сами себя ограничивают в таких случаях, помня, какие данные можно менять из данного места, а какие нельзя.
Со всем уважением, но твои доводы похожи на аргументы очень пожилого человека, который объясняет и доказывает необходимость палочки, на которую он опирается. Мол, без нее непременно упаду. Так и есть. Но не для всех.
Очень спорно.))
возможно, но я тож "динозавр из конца 90-х" я видел еще Turbo Pascal и зачатки графики в виде библиотек из которых как ни крути - все равно получишь Norton Commander ))))
а с появлением (и моим переходом) на Delphi, как говорится тут только жизнь и началась.... я сейчас плохо представляю как можно сделать активные окошки, чекбоксы и т.п. без ООП, наверное в теории можно, но даже примерно не вижу плана как это можно без ООП реализовать, как говорится к хорошему быстро привыкаешь!
Со всем уважением, но твои доводы похожи на аргументы очень пожилого человека, который объясняет и доказывает необходимость палочки, на которую он опирается. Мол, без нее непременно упаду. Так и есть. Но не для всех.
Ты, как я помню, прекрасно помнишь все, что лежит в твоем огромном массиве данных. А я вот подобных вещей - не помнил даже когда был молод. Сейчас, когда я уже старпер - я и подавно не могу вспомнить все, что имел ввиду, когда писал тот или иной блок. Мне эта "палочка", действительно, очень помогает. Но, я согласен, что если кто-то способен все необходимое удерживать в памяти - то без нее можно и обойтись.
Тем не менее, я уже несколько раз приводил в пример код уважаемого fxsaber'а, в котором он мне сам не смог сказать, как именно он работает. Просто там весьма хитрые и неочевидные проверки, которые помнить, и в самом деле, сложно. И человек не помнит. Сошлись на том, что "этот код многократно проверен, так что ему можно доверять". Но, что будет, если какие-то протоколы работы изменятся ? Код сразу становится невалидным, и при этом - вместо того, чтобы поправить то, что изменилось - придется его заново изучать, пока не будет найдено это самое измененное место.
Вот для того и нужны эти самые "палочки". Программные продукты сейчас настолько сложны, что держать в голове все их тонкости - просто нереально. Именно для этого и используются различные методики (ООП - лишь одна из них).