Вопросы по ООП (Объектно Ориентированному Программированию ) - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Как всегда, хотел научится, но обязательно найдутся те, кому кроме как поумничать и сказать больше нечего ...
Я написал простой пример что бы его разобрать, я не знаю как более грамотно написать с ООП ... Это просто пример, если знаете как написать подобный код правильно и ООП тогда пожалуйста напишите, что бы я и другие могли научиться...
ООП начинается с поиска объекта. Если объекта нет, то нет ООП.
Обычно, объект это какие-либо ресурсы, данные.
Надо просто писать и смотреть, как другие пишут. Потом само дойдёт. Ещё можно учебники читать. Их полно в инете.
ООП начинается с поиска объекта. Если объекта нет, то нет ООП.
Обычно, объект это какие-либо ресурсы, данные.
Надо просто писать и смотреть, как другие пишут. Потом само дойдёт. Ещё можно учебники читать. Их полно в инете.
Порекомендуйте пару учебников пожалуйста ... Наиболее простые и полезные на ваш взгляд ...
Порекомендуйте пару учебников пожалуйста ... Наиболее простые и полезные на ваш взгляд ...
Гради Буч. "Объектно-ориентированный анализ и проектирование. С примерами приложений на C++"
Ирэ Пол (иногда пишут Айра Пол) "Объектно-ориентированное программирование на C++"
1) Не имеет отношения к ООП, но обработчик ошибок торговых операций (OrderSend(), OrderDelete(), OrderModify() ) надо бы добавить...
Чтобы имело отношение к ООП - сделать как виртуальный метод класса (чтобы в классах-потомках можно было перекрыть, добавив обработку др. кодов).
2) Все методы класса, которые в классах-потомках могут работать не так как сейчас - сделайте виртуальными (virtual).
Первый кандидат - openorders().
Из минусов - в виртуальных методах нельзя менять число и тип параметров.
Из плюсов - "старые" Buy, Sel, BuyStop и пр. смогут вызывать "новый" (измененный в классе-потомке) openorders()
3) Давайте сразу более красивые имена. OpenOrders вместо openorders, например.
4) Если в терминологии принято как-то называть, то и Вы пользуйтесь подобной терминологией.
Если продажа = SELL, то и Вы называйте Sell или SELL (т.е. SellStop вместо SelStop)
5) Надо убрать из класса все константы (500 и пр).
Пусть берутся из переменных или задаются как параметры методов.
Сейчас вы помните про 500 зашитых в openorders(), а потом забудете или будет написано куча совов, использующих эти классы и будет сложно менять что-то.
Сложнее всего исправляются архитектурные ошибки.
А вы сейчас именно скелет создаете (если это не просто упражнение).
6) Не суйте всё в один класс.
Сделайте класс clOrder и к нему прикрутите SetSL, CloseOrder, GetSL, GetProfit, SetTP, GetTP и пр.
А в класс clTrade зашейте массив/список ордеров, символ и свойства символа (TICKETSIZE, POINT, TICKETVALUE, MINLOT, MAXLOT, STOPSTEP, LOTSTEP, LOTSIZE и пр.).
Если прикрутите Ask и Bid (как свойства символа) то не забывайте их обновлять в OnTick().
К RefreshRates() сделайте обвязку, чтобы после обновления переменных МТ вызывалось обновление свойств Ask и Bid (у меня еще проверяется статус ордеров, кто открылся и кто закрылся. Закрытые вычеркиваются из списка ордеров).
Можно прикрутить расписание торговли (тоже сначала сделав класс) и трейлинг-стоп (тоже сделав отдельный класс).
PS: Я это всё проделал на выходных (сделал библиотеку для торгов), но в этот раз решил без классов обойтись (только структуры, массивы структур и функции, которые со всем этим работают).
Там ещё расписание есть на каждый день (т.к. у Альпов по золоту есть перерыв каждый день с 0:00 по 1:00). В последние 2 минуты торгов функция проверки расписания закрывает все трейды и отменяет все ордера.
А в последний час торгов - закрывает убыточные трейды, отменяет ордера и тралит прибыльные трейды. Трейлинг тоже сделал. Одного вида, но за счет разных параметров - для разных символов подходит.
Схема такая - Символы (со своими полями), Ордера (со своими полями), Расписания (со своими полям) и Советник, который имеет свои поля (магик и пр), ссылается на Символ, имеет список Ордеров и список Расписаний.
Вершина иерархии - список Советников (комбинация символ+магик должна быть уникальной).
Порекомендуйте пару учебников пожалуйста ... Наиболее простые и полезные на ваш взгляд ...
В CodeBase сейчас появляются примеры, написанные с применением ООП. От VOLDEMAR'a, например )))
Собственно, Ваш https://www.mql5.com/ru/code/11159 и сподвиг меня на перенаписание торговой библиотеки под структуры.
С классами решил пока подождать - не вижу пока смысла в MQL это пока использовать.
Или он стандартный только в MQL5, а в новый метаедитор просто перекочевал оттуда.
В CodeBase сейчас появляются примеры, написанные с применением ООП. От VOLDEMAR'a, например )))
Собственно, Ваш https://www.mql5.com/ru/code/11159 и сподвиг меня на перенаписание торговой библиотеки под структуры.
С классами решил пока подождать - не вижу пока смысла в MQL это пока использовать.
Да это я писал но кроме переноса функций в класс я пока больше ничего не понял,
Да это я писал, но кроме переноса функций в класс я пока больше ничего не понял,
3(+1) принципа ООП:
1) Инкапсуляция. Т.е. хранение переменных, псевдо-переменных (именуемых "свойствами объекта" или просто "свойства") в самом объекте. Т.е. при правильном объявлении класса его данные не могут быть изменены извне.
Только путем использования функций самого класса (именуемые "методы класса" или просто "методы"). Нужно для того, чтобы не просто присвоить значение какой-либо переменной, но и выполнить какие-то действия в связи с изменением этих полей.
И это - основная (на мой взгляд) полезность введения ООП в MQL, а не перенос функций (функции моей торговой библиотеки получают индекс советника как один из параметров и работают с выбранным советником, в т.ч. с его массивом ордеров).
Никто кривыми руками не может залезть в данные созданного Вами класса (если нет исходников), а потом разводить гнилость, что Ваш код работает с ошибками.
2) Наследование. При создании класса-потомка он наследует все поля и методы класса-предка (есть тип private для полей и методов, которые нельзя видеть в классах-наследниках, но это мы пока тут опускаем).
Вот тут на этапе проектирования объекта нужно четко продумать архитектуру - как будет этот класс использоваться, какие поля в него включать, как они должны быть видны в потомках и пр.
Используется в мощных системах и библиотеках классов, для задач, уровень которых лично я не вижу в задачах торговли. Но может быть кому-то будет нужно. Можно делать классы-потомки с разными трейлинг-стопами, например.
Именно поэтому - никаких констант внутри методов, всё должно задаваться извне через соответствующие методы (обычно начинаются на .Set) или непосредственно как параметры методов. Это я про ваши 500.
3) Полиморфизм. То что я написал несколькими постами выше - когда переделанную в классе-потомке функцию openorders() будут спокойно вызывать старые функции Buy() и пр.
В качестве примера полиморфизма приводят вычисление площади геометрической фигуры для разных фигур.
Для круга вычисляется одним способом, для квадрата - другим. Но в любом случае - вызвав Figura.GetSquare(), мы получим площадь конкретной фигуры, унаследованной от базового класса (если мы там не забыли объявить Square() ).
Опять же требуется определенная квалификация для создания архитектуры базового класса. Например, забыв объявить Square() как virtual, Вы лишитесь возможности вызывать Square общим способом (придется перед каждым вызовом проверять тип класса и вызывать именно его реализацию Square).
Некоторые рекомендуют все методы, кроме конструкторов, делать виртуальными (я придерживаюсь этой же точки зрения, если при создании класса не видны горизонты во что этот класс может вырасти). Главное - деструкторы тоже виртуальные должны быть.
Update:
================
4) Абстракция (по просьбам камрадов, хотя когда я изучал ООП (в 1990-х) это не считалось принципом (ибо на самом деле - просто вытекает из первых трех), да и в статье (см. ссылку ниже) про нее написано, но в заголовке статьи её нет, там только 3).
В практическом применении - это создание "пустого" базового класса (где методы объявлены, но ничего не делают). В некоторых языках метод можно так и пометить abstract. Что означает, что в классе-потомке он должен быть обязательно перекрыт (т.е добавлен метод, который что-то делает).
===================
PS: кратенько, не влезая в дебри можно почитать тутPPS: Не хочу никого обидеть, но когда я в Работе запросил написание торговой библиотеки, только 1 чел ответил, что у него она есть и он её использует.
5 MQL-прогаммистов (в Skype) сказали, что не имеют понятия, что в ней должно быть и они копи-пэстят нужные функции из одного своего сова в другой. В плоть до того, что втыкают RefreshRates() между участками кода, которые ничего не меняют и не могут выполняться больше нескольких миллисекунд. Да и последующий код от изменившихся Ask и Bid и (может быть измененных типов ордеров) никак не зависит.
По-этому для MQL-программистов, не работавших с ООП ранее в других языках программирования, ООП в MQL пользы не принесет. Как максимум - спрятать данные от внешнего изменения (что тоже не плохо).
3 принципа ООП:
1) Инкапсуляция. Т.е. хранение переменных, псевдо-переменных (именуемых "свойствами объекта" или просто "свойства") в самом объекте. Т.е. при правильном объявлении класса его данные не могут
2) Наследование. При создании класса-потомка он наследует все поля и методы класса-предка (есть тип private для полей и методов, которые нельзя видеть в классах-наследниках, но это мы пока тут опускаем).
3) Полиморфизм. То что я написал несколькими постами выше - когда переделанную в классе-потомке функцию openorders() будут спокойно вызывать старые функции Buy() и пр.
В качестве примера полиморфизма приводят вычисление площади геометрической фигуры для разных фигур.
Для круга вычисляется одним способом, для квадрата - другим. Но в любом случае - вызвав Figura.GetSquare(), мы получим площадь конкретной фигуры, унаследованной от базового класса (если мы там не забыли объявить Square() ).
Где же четвёртый?! Где абстракция! Незаслужанно забыли :-(
Добавьте.