ООП vs процедурное программирование - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
George Merts:
Ээээ... Не совсем понял суть.
Задача была - отделить ТС от терминала. Чтобы код без изменений - компилировался на обоих платформах. Сверхзадача - чтобы можно было, написав лишь классы работы с торговым сервером - перенести все написанные ТС на WealhtLab Developer.
//--------------------------------------------------
Я спрашивал о текущей задаче для того, чтобы сравнить ее решения по нескольким критериям и прийти к выводу о эффективности каждого. Ты уводишь разговор от практической части. Утверждая эффективность применения ООП, нужно уметь это доказывать на практике. Я же готов попробывать доказать свое мнение.
И так, в чем текущая задача? Надеюсь ты ее помнишь)
Если использовать указатели на функции, то можно обойтись без ООП. Если же нет указателей, то вы должны сами понимать, что ООП не догнать.
Я так понимаю, ты не программист? Тогда вспомни, где ты был 2017.07.05 14:55 GMT 00, с кем беседовал и о чем ))
Если использовать указатели на функции, то можно обойтись без ООП. Если же нет указателей, то вы должны сами понимать, что ООП не догнать.
Нет. Пока нет конкретной задачи которая мне покажет, что ООП не догнать, я никак не могу это усвоить. К сожалению. Это просто слова.
На данный момент моя практика программирования 4 года. Их смело можно умножить на 2, потому что я программирую каждый день по много часов. За все это время я решил бесчисленное количество самых разных задач. Еще ни разу не применял ООП. Я никак не могу понять, зачем он нужен. В моей практике любые задачи решаются без него не менее, а иногда и более эффективно.
Нет. Пока нет конкретной задачи которая мне покажет, что ООП не догнать, я никак не могу это усвоить. К сожалению. Это просто слова.
Представьте гипотетическую программу, которая меняет свой алгоритм в зависимости от внешних параметров, вариантов может быть огромное количество. Можно и без ООП решить, но как будут тупо выглядеть эти многоэтажные switch. Притом, здесь явно понятно, что быстродействие будет снижаться с увеличением количества возможных вариантов. Так же явно понятно, что с ООП происходит построение при инициализации, а дальше, в процессе работы никаких лишних ветвлений, т.е. увеличение вариантов не будет вести к снижению быстродействия.
Отличительной чертой структурного программирования является разбиение программ на блоки кода,
выполняющие какую-то определённую задачу. При этом структурными единицами являются функции
и модули (которые могут выноситься в отдельные файлы).
Более современным является объектно-ориентированное программирование (ООП).
Понятие ООП больше относится к организации данных. ООП делает жизнь программиста легче.
Ключевыми понятиями в ООП являются объекты и классы.
Классы - это структуры, в которые добавили функции. А объекты - это структурные переменные или экземпляры классов
Структурное программирование - первая ступень. Освоив ее программист получает преимущество. ООП - следующая ступень со следующим преимуществом
Давайте решим конкретную задачу и сравним.
Вот допустим такая простая задача (чтобы детально объяснить, надо много писать).
Всё происходит в OnTick(). Допустим проверяем какое-то условие и открываем ордер. Условие не важно, допустим это какие-то макс. или мин.
Естественно робот на каком то графике стоит, котировки этого символа и получает. Понятно что тут не только одна функция OnTick, есть и другие: OnTrade, OnTimer, собственные функции и т.д.
Следовательно надо все переменные которые общие, объявить вне этих функций, в начале кода. Например такие, как имя символа, аск, бид, спред, количество знаков котировки и т.д. Их будет несколько десяток.
Этот робот будет торговать только на одном символе, т.е. там где он стоит. Таких графиков допустим 20, и на всех устанавливаем тот же робот, чтобы одновременно торговал для всех 20 пар.
Но это не мультивалютный робот, как некоторые указывают в Маркете.
Вот требуется его превратить мультивалютника. Т.е. его ставим на любой график(только на 1 график), а он открывает сделки для 20 пар. Т.е мы его запускаем на тестере в одиночном режиме, а он торгует с теми парами, которые находятся в Market Watch.
Вот как будете без ООП это осуществить. Все общие переменные будете превратить в массивы из 20 -и элементов ?
А как быть с функциями, которые будут вызваны одновременно для всех пар ?
Вот и без ООП не обойтись. :)
P.S. Хочу отметить, что у меня не русское образование, и поэтому долго написал, и не успел прочитать несколько страниц.
Если использовать указатели на функции, то можно обойтись без ООП. Если же нет указателей, то вы должны сами понимать, что ООП не догнать.
Не согласен. В свое время писал программы под цифровое телевидение, компилятор был С++, но использовали в рамках Си, так как памяти было мало. Указатели на функции использовали очень широко, но это рядом не стоит с ООП.
...
Вот как будете без ООП это осуществить.
...
Тут скорее уместен вопрос не "как", а "зачем"? Зачем кодить то, что и так уже реализовано в терминале - просто надо открыть нужное количество графиков и повесить на них по эксперту. К тому же на разных символах и таймфреймх параметры, скорее всего, должны быть разные.
Не согласен. В свое время писал программы под цифровое телевидение, компилятор был С++, но использовали в рамках Си, так как памяти было мало. Указатели на функции использовали очень широко, но это рядом не стоит с ООП.
По удобству не стоит рядом, но по возможностям обеспечения быстродействия - можно обойтись одними указателями.
А удобство - понятие относительное.
Представьте гипотетическую программу, которая меняет свой алгоритм в зависимости от внешних параметров, вариантов может быть огромное количество. Можно и без ООП решить, но как будут тупо выглядеть эти многоэтажные switch. Притом, здесь явно понятно, что быстродействие будет снижаться с увеличением количества возможных вариантов. Так же явно понятно, что с ООП происходит построение при инициализации, а дальше, в процессе работы никаких лишних ветвлений, т.е. увеличение вариантов не будет вести к снижению быстродействия.