Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Vladimir:
Может быть, для организации интерфейса с пользователем? Вот уж где наворочено множество вариантов на ООП, одна библиотека визуальных компонентов Delphi чего стоит. Так советники и скрипты призваны заменять человека у компьютера, этот интерфейс прямо противоречит их назначению, не нужен. То есть мешает. Также, как лишние предметы в перочинном ножичке. Или гвоздодер на конце стальной ручки универсального молотка - не только царапает, но и смещает центр тяжести от бойка к ручке.
В этом конкретном пункте не соглашусь с Вами.
Графический интерфейс может быть нужен алготрейдерам, которые понимают, что полностью автоматизированный советник, на сегодняшний день, значительно менее эффективен, чем полуавтоматический. Совмещение автоматического и ручного трейдинга может быть более профессионально и прибыльно с точки зрения трейдинга. Когда люди это поймут, интерфейс их роботам точно понадобится.
1. Идентификатор_графика читается русскоязычным человеком быстрее чем m_chart_id.
2. Если в программе сотни переменных, то русский язык оказывает незаменимую поддержку.
Все это можно проверить в эксперименте.
Скорость чтения и осмысления кода на родном языке всегда будет выше, а запоминание лучше.
Надо просто разработать правила именования переменных на русском. Вместо "переменная_для_хранения_общей_прибыли _позиции, - просто: Общая_прибыль.
Если в программе сотни переменных, то большую часть наверняка можно объединить структурами. Так же не забываем пользоваться функциями.
Многие переменные вообще не несут смысловой нагрузки, т.к. являются счетчиками, временными хранилищами промежуточных данных и используются за кучей скобочек. И что самое приятное, за всеми скобочками можно опять использовать эти же переменные, но опять же в скобочках {....}
Или изначально писать в ООП.
Мне кажется суть его отторжения ООП кроется в этом. Могу ошибаться конечно, но обычно чувствую людей.
На мой взгляд, проблема большинства, неприемлющих ООП во внутреннем сопротивлении к "ограничение законных прав".
Олдскульный программер привык к тому, что у него в любой момент есть полный доступ к любым данным, к любому блоку, к любой сущности программы. А ООП-подход - подразумевает обратное - максимальное ограничение прав, когда ты - имеешь доступ к очень небольшой части данных и действий программы.
По себе помню - это мне очень не нравилось. Во времена только начала Windows, я помню, как меня страшно возмущал защищенный доступ к памяти - это как же, я не имею возможности обратиться к тому адресу, который мне нравится, ну и что, что он в ядре системы ? Я, может быть, хочу из программы его или прочитать, или вобще изменить ! Доходило до того, что программировал контроллер прямого доступа к памяти, который бы пересылал в "разрешенную область" данные из "запрещенной", в обход ограничений системы.
Но, со временем я очень заценил все эти ограничения. "Лишний" доступ всегда может обернуться ошибками. Поэтому очень разумно перенести работу по контролю доступа - на компилятор. Ограничение доступа здесь оборачивается не "ущемлением твоих прав", а "защитой от дурака". Если же тебе нужен доступ, которого у тебя нет - это всего лишь означает неправильное проектирование системы - надо было предусмотреть возможности такого доступа, раз он нужен.
И сейчас - я наоборот, всегда по-максимуму ограничиваю доступ. В любой точке должен быть доступ только к тем сущностям, к которым необходимо. Все остальные объекты - должны быть недоступны. Это оберегает тебя от ошибок с доступом туда, куда не следует, а кроме того, приучает к определенной последовательности разработки систем, когда каждая операция производится в одном месте, и не затрагивает никаких других мест.
Я например терпеть не могу инклюдники в виде библиотек, тупо потому что не знаю что туда напихали и как это мне поможет, проще написать еще десяток функций
по аналогии с Реter Konow.
И почему ?
Одна и та же функция требуется во многих местах - зачем копипастить функции, если можно иметь все в библиотеках, и не загромождать основной код лишними блоками ?
И почему ?
Одна и та же функция требуется во многих местах - зачем копипастить функции, если можно иметь все в библиотеках, и не загромождать основной код лишними блоками ?
Умеешь ты Николай находить аргументы.)
Бабушка тоже все усвоить может без проблем. Она просто подсознательно не хочет, чтобы какая то безделушка затягивала ее устоявшийся разум в круговорот ненужной информации. Правильно делает.)
Пётр, так вы оказывается бабушка.
Здравствуйте
Возможно здесь мне помогут. Есть вопрос к разработчикам МТ4. Где его можно озвучить. Если на этом форуме, то в какой ветке? Или где то на другом ресурсе? Если знаете подскажите пожалуйста.
В этом конкретном пункте не соглашусь с Вами.
Графический интерфейс может быть нужен алготрейдерам, которые понимают, что полностью автоматизированный советник, на сегодняшний день, значительно менее эффективен, чем полуавтоматический. Совмещение автоматического и ручного трейдинга может быть более профессионально и прибыльно с точки зрения трейдинга. Когда люди это поймут, интерфейс их роботам точно понадобится.
Вы же полностью поддерживаете человека, который говорит, что в mql должны быть лишь функции доступа к серверу, а всё остальное через костыли должно программироваться сторонними средствами разработки. Не отклоняйтесь от линии партии. Будьте последовательными - грохайте все свои наработки на mql и делайте мост - в студию например - или где вы там будете писать свои полотна... Потом отчитайтесь уж об очередной своей победе над мельницей.
Я например терпеть не могу инклюдники в виде библиотек, тупо потому что не знаю что туда напихали и как это мне поможет, проще написать еще десяток функций
по аналогии с Реter Konow.
Ну и закон сохранения энергии: зачем декомпилировать библиотеку и разбираться в ней если все работает без нее?
З.Ы
мой топ про лосей не встречался?
Когда ваши коды начнут переполнять 10, 20, 30, ... ,100 тысяч строк, тогда вернитесь и расскажите как вы копипастите свои коды в таком объёме.
На мой взгляд, проблема большинства, неприемлющих ООП во внутреннем сопротивлении к "ограничение законных прав".
Олдскульный программер привык к тому, что у него в любой момент есть полный доступ к любым данным, к любому блоку, к любой сущности программы. А ООП-подход - подразумевает обратное - максимальное ограничение прав, когда ты - имеешь доступ к очень небольшой части данных и действий программы.
По себе помню - это мне очень не нравилось. Во времена только начала Windows, я помню, как меня страшно возмущал защищенный доступ к памяти - это как же, я не имею возможности обратиться к тому адресу, который мне нравится, ну и что, что он в ядре системы ? Я, может быть, хочу из программы его или прочитать, или вобще изменить ! Доходило до того, что программировал контроллер прямого доступа к памяти, который бы пересылал в "разрешенную область" данные из "запрещенной", в обход ограничений системы.
Но, со временем я очень заценил все эти ограничения. "Лишний" доступ всегда может обернуться ошибками. Поэтому очень разумно перенести работу по контролю доступа - на компилятор. Ограничение доступа здесь оборачивается не "ущемлением твоих прав", а "защитой от дурака". Если же тебе нужен доступ, которого у тебя нет - это всего лишь означает неправильное проектирование системы - надо было предусмотреть возможности такого доступа, раз он нужен.
И сейчас - я наоборот, всегда по-максимуму ограничиваю доступ. В любой точке должен быть доступ только к тем сущностям, к которым необходимо. Все остальные объекты - должны быть недоступны. Это оберегает тебя от ошибок с доступом туда, куда не следует, а кроме того, приучает к определенной последовательности разработки систем, когда каждая операция производится в одном месте, и не затрагивает никаких других мест.
Ты привел хороший пример того, чем может отторгать ООП.
В моем случае было немного по другому. Я решительно взялся за изучение ООП, но на определенном этапе перестал видеть какую либо практическую пользу его использования. До сих пор это так и не изменилось. Все потому, что у меня сформировался мой подход, который и вытеснил ООП из моей практики.
Вот это утверждение, - что ограничение доступа эта необходимая защита, которая спасает от ошибок, я никак понять не могу. При совпадении имен переменных в разных частях программы, - несомненно да. Но если есть общая глобальная память всех основных глобальных переменных в одном массиве, то ограничения не нужны и никакой путаницы не будет.