МТ4 или МТ5. Какие преимущества и недостатки? - страница 42
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Для начала нужно еще понять что именно этот интерфейс делает, куда и как подсоединяется и при каких условиях, а это уже целая немаленькая логика витеиватая со своими фокусами, которую еще нужно каждый раз вспоминать - и это при том что никаких полезных вычислений тут не производится.
И это для самого простого проекта, а что будет если проект будет чуть посложней?
Как раз для простого проекта - такие навороты не нужны. Все - на ладони, все можно "охватить мысленным взором". Проблемы начинаются, когда проект начинает расти.
Ответ на вопрос "как подсоединяется интерфейс и на каких условиях" - должен быть также как можно проще. Интерфейс должен быть таким, чтобы его просто невозможно было бы подключить иначе.
Вот, тот же вышеприведенный интерфейс позиции. После ее выбора - пользователь может прочесть компоненты (ордера МТ4 или позиции МТ5), запросить все свойства каждой, но даже при желании - он ничего не сможет изменить. Если бы это была структура данных, то изменить ее поле - вполне реально. Сперва это делается для каких-то текущих целей, временно, но потом - забываем "вернуть" код к исходному состоянию - и пожалуйста, имеем ошибку (которая у меня пару раз когда-то, еще в студенческие времена, случалась).
Andrei:
Также вопрос о том должен ли программист, севший писать код, придумывать средства против самого себя мы уже обсуждали - если программист в трезвом уме и временно не пьян, то "защиты от дурака", то есть от него самого, ему не нужны в принципе, не говоря уже о том что это затрудняет понимание логики, потому что дурак при желании всегда найдет способ как себя обдурачить и эта борьба двух дураков имеет непредсказуемый результат.
Мой опыт показывает, что "защита от дурака" нужна обязательно, именно от себя самого. Я уже неоднократно благодарил сам себя за подобные ограничения, когда хотел что-то изменить, а в интерфейсе не было таких возможностей, я возмущался, мне казалось это глупостью, но начав разбираться - я неожиданно наталкивался на тонкость, про которую уже не помню, но которая как раз и ограничивала возможности интерфейса.
В последние годы я такие тонкости - всегда описываю в коде подробными комментариями, что мне также очень помогает. Хочу иметь доступ - доступа нет. Почему ? Начинаю разбираться по коду, натыкаюсь на этот самый большой комментарий, читаю, и вспоминаю, ах да, действительно, доступ в том месте неразумен. Делать надо иначе. И так было неоднократно.
От кривых ручек защиты нет. )) Нужно просто корректно описать логику функции, а не городить огород со всякими ограничениями.
Например, исключения и их обработка - любой адекватный программист скажет что от этого только вред, так как логика функции должна быть описана полностью, чтобы исключений не возникало в принципе.
Проблема в том, что человеку свойственно ошибаться и забывать. Поэтому "кривые руки" у него изначально. И именно всякие ограничения и позволяют "не наделать делов" с этими самыми "кривыми ручками".
Что же касается исключений - то я, видимо, неадекватен, поскольку считаю исключения очень даже хорошим инструментом, и в С++ всегда их широко использую, наряду с кодами возврата. В MQL исключений нет - я использую только коды возврата. Большой разницы не вижу, можно использовать и то, и другое, спор "код возврата vs исключение" - скорее религиозен.
Мой опыт показывает, что "защита от дурака" нужна обязательно, именно от себя самого. Я уже неоднократно благодарил сам себя за подобные ограничения, когда хотел что-то изменить, а в интерфейсе не было таких возможностей, я возмущался, мне казалось это глупостью, но начав разбираться - я неожиданно наталкивался на тонкость, про которую уже не помню, но которая как раз и ограничивала возможности интерфейса.
Это и то что вы массово используете исключения говорит о проблемах адекватного описания логики, которую вы пытаетесь реализовать. Как эта болезнь лечится - есть разные методы, но это уже не из области программирования... Программирование это язык изложения своих мыслей, а если у человека проблемы с формулированием своих мыслей и логическим мышлением, то нужно искать подходящие средства для исправления симптомов...
Даже если и есть какой-то случай когда функция ведет себя некоректно, то это можно просто пометить в коде в виде сообщения - интерфейсы тут явно не в тему приплетаются непонятно каким боком.
И еще про ООП, объект - это тип данных и вроде бы работают с ним как типом данных, например объявление объекта и т.п.
Но сразу видна полная неадекватность тех кто это все придумывал ибо к этим данным начисто отсутствует доступ извне и нормально работать с ними как с данными практически невозможно.
Более того эти данные имеют способность неконтролируемо накапливаться и нужно придумывать всякие извращения как за всем этим следить...
Не будем говорить про структуры - это логичный тип данных ибо это тупо было украдено из Си и ООП деятели просто не смогли это испоганить...
Забавно читать разглогольствования человека, который не может справиться с собственной ошибкой индексации в массиве. За 7 лет публикаций данного поста дальше массивов уйти видимо так и не удалось.
Забавно читать разглогольствования человека, который не может справиться с собственной ошибкой индексации в массиве. За 7 лет публикаций данного поста дальше массивов уйти видимо так и не удалось.
Вы бы еще из детсада моего выискали бы пример и сделали бы далеко идущие выводы на всю оставшуюся жисть. )) Спасибо, повеселили...
А что делать, если ничем кроме дедсадовских кодов Вы неизвестны. Предъявите хоть один реализованный проект средней руки для подтверждения своих слов. Ах да, таких у Вас нет.
А что делать, если ничем кроме дедсадовских кодов Вы неизвестны. Предъявите хоть один реализованный проект средней руки для подтверждения своих слов. Ах да, таких у Вас нет.
А у вас самого есть интересненькое хоть что-то предьявить?)
Вот поэтому логика должна быть прозрачной - какой тикет пользователь установил тот и должен исполняться, а не тот что задумал создатель класса. Это приводит к куче непоняток бессмысленных.
А вот это сейчас что было?
Что значит "какой тикет пользователь установил, тот и должен исполняться"? Куда тикет должен исполняться? Тикет назначается сервером ордеру/позиции при его установке. А не сам пользователь.
Пользователю разрешено только получить этот тикет и работать с ним, и тоже в рамках дозволенного.
Давайте я вам так скажу: сам терминал по отношению к пользователю является классом с закрытыми методами. Вы сами лично не вправе менять в списках истории терминала номера тикетов. Но получать вы их можете. И далее работать можете только с тем ордером, который получили из терминала.
Или вы будете утверждать, что и терминал придумали ООП-деятели, и вам срочно нужно дать доступ к изменению всех элементов терминала - от интерфейса до текстов?
Artyom Trishkin:
Вы сами лично не вправе менять в списках истории терминала номера тикетов. Но получать вы их можете.
Ну так если менять ордера невозможно изначально, то зачем еще и запреты на уровне классов какие-то выстраивать?
Даже если каким-то образом пользователь это изменит с помощью ваших классов, которые как-то могут умудриться залезть в историю терминала чтобы это сделать, то все равно смысла в этом нет, так как на сервере содержатся настоящие номера.
В общем как-то здравый смысл не просматривается в этих телодвижениях, которые вы предлагаете совершать, агитируя за ООП.
Ну так если менять ордера невозможно изначально, то зачем еще и запреты на уровне классов какие-то выстраивать?
Даже если каким-то образом пользователь это изменит с помощью ваших классов, которые как-то могут умудриться залезть в историю терминала чтобы это сделать, то все равно смысла в этом нет, так как на сервере содержатся настоящие номера.
В общем как-то здравый смысл не просматривается в этих телодвижениях, которые вы предлагаете совершать.
У-у-у... как всё запущено...
Тикеты были просто абстрактным примером.
И вот если вы в СВОЕЙ программе, получив тикет из терминала, потом это значение сами меняете - мол не хочу я работать с этим, а хочу работать с другим - с которым я хочу - то тут логика вашей программы словит нокдаун - вы вписали в свою программу тикет, которого нет, или тикет, с котором в данный момент не нужно работать, но вы так захотели, и вписали его... и вот с этого момента начинается для вас и вашей программы целый комплекс мероприятий, который называется частью тела что пониже спины будет.
Если же вы работаете с классом, который вам не позволит заменить существующий тикет на вами выдуманный, то и проблем у вас не будет... ну кроме той, что вы будете считать, что вас ограничили.