Используете ли вы ООП в программировании на MQL4 и MQL5? - страница 7
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Не использую ООП и не собираюсь, всё что нужно для торговли есть в MQL4
Не использую ООП и не собираюсь, всё что нужно для торговли есть в MQL4
Нужно смотреть шире чем мт4/мт5.
Ясно понятно, что не просто так ООП это господствующая на сегодняшний момент парадигма. Без ООП будут просто огромные тонны куски кода, плохо структурированные и упорядоченные. Соответственно он будет плохо повторно использоваться, может возникнуть проблема "повторяемости" кода и т.д.
То что есть люди старой закалки, которые вообще не захотят принимать ничего нового это факт, они не плохие люди, нет, просто они закончили учиться, а это очень плохо для программиста. Я думаю тому товарищу и система контроля версий git тоже никаких преимуществ не дает. Однако эта вещь очень популярная, и говорят, удобная.
Совершенно точно про старые закалки. Я токарь, и вот все старые токаря были без ума от токарного станка 1К62, молодежь уже предпочитала поновей 16К20, а грузины пошли еще дальше, они объединили эти два станка в один (и тем и тем), на вид 16К20, а внутренности 1К62. Так что надо ждать новый вид. Или переставать спорить. Кому как нравится тот так и пишет код, главное что бы он работал и исполнял желания в точности с заданными параметрами желаний. В ООП самая привлекательный момент - это наследование и частичная правка наследников и ограничение в доступе. А так все тоже самое(то была бы написана еще одна функция, а то появился наследник), результат один и тот же. Если ты забываешь все в первом случае(как я к примеру), то и во втором случае так же будешь все забывать: тоже одно и тоже. Так что, кому как нравится тот так и пишет.
В ООП самая привлекательный момент - это наследование и частичная правка наследников и ограничение в доступе.
Наоборот, наследование создает кучу проблем с поддержкой кода, да и ситуация когда можно так сгруппировать функции чтобы была общая наследуемая часть - редкая. Да и читаемость кода сразу падает на порядок, цепочку наследования нужно держать в голове либо постоянно освежать в памяти чтобы не забыть. Выглядит как бесполезная вещь.
Ограничение доступа тоже миф, и это скорее несет вред чем пользу так как становится невозможно передавать переменные из одного класса в другой.
Был тут аргумент что бывает когда программист не трезв и может взять "не те" переменные, ну дык он может с таким же успехом попортить код в других местах.
Наоборот, наследование создает кучу проблем с поддержкой кода, да и ситуация когда можно так сгруппировать функции чтобы была общая наследуемая часть - редкая. Да и читаемость кода сразу падает на порядок, цепочку наследования нужно держать в голове либо постоянно освежать в памяти чтобы не забыть. Выглядит как бесполезная вещь.
Ограничение доступа тоже миф, и это скорее несет вред чем пользу так как становится невозможно передавать переменные из одного класса в другой.
Был тут аргумент что бывает когда программист не трезв и может взять "не те" переменные, ну дык он может с таким же успехом попортить код в других местах.
Ну нет.
Как раз наследование для того и нужно, чтобы не держать в голове цепочку наследования.
И потом - как раз и ограничить доступ, чтобы не влезть и не испортить ничего.
Запросил интерфейс, в нем одни чисто виртуальные функции, ничего испортить нельзя.
Когда то (конец 90-х), когда учил некоторым желающим с низкими способностями, понять что такое классы, объекты, объяснил так.
Вот например в вашем доме есть стол, стулья, ложки и т.д, в том числе и сейф. Допустим, что к сейфу не все челны семьи имеют доступ. Но вот ваш друг из соседнего дома должен иметь доступ к вашему сейфу.
Вот жители из чужих домов, не смогут приходить в ваш дом и забрать ваши стулья, ложки . . . они защищены.
А вот в магазин может войти любой бомж, но не сможет войти в здание парламента. Вот как сделать, чтобы в лесу шишки были общими, а ваш огород был защищен от посторонних.
Вот сейчас допустим вы работаете в группе, где разрабатывают отдельные части одной большой системы. Во всех программах допустим есть понятие времени и надо каким то образом объявить его.
Из 10 программистов если не 10, то 8 точно, будут использовать имя "time". Вы представляете что будет если после завершения, будут объединить все эти модули, где везде используются переменные с одинаковым названием "time".
Будет каша и неразбериха.
Вот классы это уже порядок и дисциплина, это демократия, где каждый четко знает что можно, а что нельзя. Это философия и описывает нашу жизнь.
P.S. Всё это на уровне школьника и для тех, кто не понимает всю мощь ООП :)
Когда то (конец 90-х), когда учил некоторым желающим с низкими способностями, понять что такое классы, объекты, объяснил так.
Прям звёздная болезнь какая-то. Я бы поскромнее был т.к. со сказанных слов не очень понятно преимущества перед
Немного доточить закрыв доступ бомжам и прям конфетка.
P.S: больше похоже на "Всё это от школьника на уровне школьника и для тех, кто не понимает всю мощь ООП :)"
Прям звёздная болезнь какая-то. Я бы поскромнее был т.к. со сказанных слов не очень понятно преимущества перед
Немного доточить закрыв доступ бомжам и прям конфетка.
P.S: больше похоже на "Всё это от школьника на уровне школьника и для тех, кто не понимает всю мощь ООП :)"
Да нет. После такого объявления "time" - во-первых, эту переменную сразу начнут использовать несколько пользователей, причем, у одного это будет - число секунд от начала программы, у другого - число тиков с начала работы системы, у третьего - время последнего обращения к него классу. И каждый из них будет тестировать свой участок - все будет проходить нормально. А когда они внесут в общий проект свои изменения - сперва вроде все заработает, а потом - начнутся непонятные ошибки.
Подобные объявления переменных на глобальном уровне - просто недопустимы. Все такие случаи должны оформляться протектед-членами классов, и доступ к ним должен осуществляться только в рамках заранее утвержденного интерфейса лишь тем, кому это необходимо.
Инкапсуляция и ограничение доступа - это очень важный момент даже в индивидуальном проекте. Когда же над ним работает несколько человек - это просто архинеобходимо.