Кто-нибудь создал успешную автоматизированную торговую систему? Что вы посоветуете? - страница 16
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Отлично! Как на счёт профита с ООП. Сразу пойдёт после изучения?
ООП дает вам возможность писать компактный, понятный элегантный код. Вы тратите на написание, модификацию и отладку кода в несколько раз меньше времени, которое стоит очень дорого. Можете построить значительно более сложную торговую систему и опробовать значительно больше торговых вариантов. Разумеется, если у вас нет идей профитного бота - то лучше вообще ничего не делать. Кроме этого, не забывайте о вероятности прямого убытка в случае баг, вероятность которых в хорошем ООП коде в разы меньше.
ООП дает вам возможность писать компактный, понятный элегантный код.
Это не так.
Это не так.
Ну, если поставить задачу специально усложнить - то да, с ООП возможностей для намеренного усложнения больше.
Но, если не уподобляться Мартышке с Очками - то код с применением ООП получается заметно понятнее, структурированнее и удобнее в поддержке.
Да я не против ООП, друзья. Мне нравится его объектная идея. И я использую его частично, правда в виде структур, вернее, массива структур. Этого достаточно в трейдинге, чтобы адресно хранить все данные с графика и не гонять циклы на каждом баре. Но, думаю, более и не требуется здесь. Конечно, можно все писать в ООП, кто привык. Но до профита им также далеко, как и процедурникам. Весь вопрос в прибыльной системе, если она есть, то можно и goto-кодом написать :)
Тема ветки парит над способом её решения.
И я использую его частично, правда в виде структур, вернее, массива структур.
В Java это даже имеет своё название: POJO (Plain Old Java Object)
;)
код с применением ООП получается заметно понятнее, структурированнее и удобнее в поддержке.
Это далеко не всегда так и зависит не от ООП, а от чистоты кода, от нейминга.
Да я не против ООП, друзья. Мне нравится его объектная идея. И я использую его частично, правда в виде структур, вернее, массива структур. Этого достаточно в трейдинге, чтобы адресно хранить все данные с графика и не гонять циклы на каждом баре. Но, думаю, более и не требуется здесь. Конечно, можно все писать в ООП, кто привык. Но до профита им также далеко, как и процедурникам. Весь вопрос в прибыльной системе, если она есть, то можно и goto-кодом написать :)
Тема ветки парит над способом её решения.
Использование структур не является ООП. Все приемущества ООП начинаются, когда вы начинаете использовать паттерны ООП. Наследование, синглтоны, фабики обьектов, интерфейсные классы и т.д. Кроме этого, без ООП не обойтись тогда, когда вас в команде более 2 человек. Например:
Далее, либо сами, либо раздаете 3 людям писать сигналы, например, по 3 разным индикаторам:
В месте, где используется сигнал достаточно сделать:
Вы, как сеньор, полностью абстрагированы от реализаций тел функций. Для вас не важна реализация и какой индикатор используется. Вы просто используете check_signal и все. В данном примере, используется одна функция. А если в классе функций много - вам придется switch вставлять в любое место, где реализация зависит от конфига или иного выбора. Кроме этого, если вы используете базу данных или скажем, лог файл в куче мест - вам приходится делать глобальную переменную и на всех этапах контролировать ее состояние (открыт ли файл или база и т.д.). В случае, если для этих целей вы используете синглтон - вы можете быть уверены, что где бы вы не использовали объект лог файла/базы - всегда будет создана одна копия объекта в которой вы можете переоткрыть базу/файл, использовать флаги состояний, делать буферизированый лог для того, что бы не писать на диск в каждом выводе и т.д. Если у вас код более 10 000 строк - то функциональщина превращается в сущий ад для разработчика. А через пол года, когда вы забудете половину своего кода - переразобраться в нем будет сущий ад. Кроме этого, хороший ООП дизайн позволяет добавлять новый функционал или править старый не боясь что все полетит к хренам если вы где то что о дрните.
А в чем разница в ООП в 5ке и 4ке? Просветите. Разница в настройках биржевого окружения явная. Ну бары с конца нумеруются. Явных других отличий по языку не вижу.
Как миниум, наконец избавились от кучи функций телескопов и самое главное, была добавлена стандартная библиотека с огромным количеством полезных классов.
Как миниум, наконец избавились от кучи функций телескопов и самое главное, была добавлена стандартная библиотека с огромным количеством полезных классов.
особенно Object.mqh
прямо по книжкам которые вы неудачно цитируете..блестящий паттерн :-)
Тема вообще не про то насколько вы освоили курс ООП и научились его адвокатствовать.. на мой взгляд хреновато освоили
в общем, собирай учебники и завтра марш в школу