ООП vs процедурное программирование - страница 37
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
У класса есть только внутренние переменные и нет входных и выходных... Где вы видели применение в программировании такого объекта, который никак не контактирует с внешним миром и варится в собственном соку?
+100
Обсуждение напомнило одно видео, ребята показывали недавно :)
У класса есть только внутренние переменные и нет входных и выходных... Где вы видели применение в программировании такого объекта, который никак не контактирует с внешним миром и варится в собственном соку?
Так погоди - у класса есть интерфейс, через который и идет взаимодействие со внешним миром. Он и позволяет отсечь все "лишнее", то, что не предназначено для посторонних блоков.
Вот, в частности, у меня в торговом процессоре - есть переменные, одни из которых предназначены для МТ4, другие - для МТ5, третьи - для обоих платформ. Но все эти переменные - совершенно не нужны ни одной из частей ТС. Соответственно, они к ним и не имеют никакого доступа. Все части ТС получают виртуальный интерфейс торгового процессора, в котором определены только необходимые для работы ТС функции, и убрано все лишнее, все платформозависимое и "торговоспецифическое".
Тоже самое с торговой позицией - части ТС - не имеют прямого доступа к торговой позиции. Они могут получить только виртуальный интерфейс, который позволяет подсчитать число открытых торговых компонент, и данные каждой компоненты. Но при этом ТС даже не знает, с чем имеет дело - то ли с ордером МТ4, то ли с позицией МТ5. Все это - от нее скрыто. ТС не должна иметь доступа к переменным, используемым для работы с ордерами в МТ4 или позициями МТ5, она и не имеет.
Так погоди - у класса есть интерфейс, через который и идет взаимодействие со внешним миром. Он и позволяет отсечь все "лишнее", то, что не предназначено для посторонних блоков.
Вот, в частности, у меня в торговом процессоре - есть переменные, одни из которых предназначены для МТ4, другие - для МТ5, третьи - для обоих платформ. Но все эти переменные - совершенно не нужны ни одной из частей ТС. Соответственно, они к ним и не имеют никакого доступа. Все части ТС получают виртуальный интерфейс торгового процессора, в котором определены только необходимые для работы ТС функции, и убрано все лишнее, все платформозависимое и "торговоспецифическое".
Давайте конкретно и очень понятный пример.
1. на входе котир
2. на выходе команда купить/продать.
3. Вход преобразовывается в выход по пересечению двух машек.
Какие между ними ООПы и зачем?
Метаквотам объясните это: зачем это они написали огромные руководства по терминалу, по языку и вообще откуда это горы документации на программные продукты например на Срр.. И вообще, бывают ли программные продукты без документации? Очень странно, что этого Вы не замечаете.
К сожалению, Вы снова подменяете понятия. Руководство программы не есть документация. Документацию вели в прошлом веке, соблюдали ГОСТы и пр. Сейчас это все не нужно. Осталось только ТЗ. Документация теперь - это тест-кейсы и интерфейсы классов. Причем классы, конечно же, названы так, чтобы по одному его названию уже было понятно, что он делает и для какой цели используется.
К сожалению, Вы снова подменяете понятия. Руководство программы не есть документация. Документацию вели в прошлом веке, соблюдали ГОСТы и пр. Сейчас это все не нужно. Осталось только ТЗ. Документация теперь - это тест-кейсы и интерфейсы классов. Причем классы, конечно же, названы так, чтобы по одному его названию уже было понятно, что он делает и для какой цели используется.
Документацию вели в прошлом веке, соблюдали ГОСТы и пр. Сейчас это все не нужно.
Здесь абсолютно с Вами согласен, так как ничего серьезного не пишут.
Всегда было ТЗ. Но столь простых программ, алгоритм которых можно полностью определить в ТЗ, попросту в прошлом веке не писали и сейчас не пишут серьезные люди.
Какие там это "тест-кейсы и интерфейсы классов" при разработке компиляторов? при программировании математических алгоритмов?
ПС.
Раньше была рубрика для перлов.
Это в нее
Руководство программы не есть документация.
Давайте конкретно и очень понятный пример.
1. на входе котир
2. на выходе команда купить/продать.
3. Вход преобразовывается в выход по пересечению двух машек.
Какие между ними ООПы и зачем?
Все достаточно просто.
Есть генератор входов. Он - запрашивает у эксперта интерфейс дата-провайдера, интерфейс торговых позиций и интерфейс торгового процессора. Затем, у дата-провайдера запрашивается два интерфейса машек.
При вызове OnTick() - вызывается эта же функция у генератора входов. Генератор входов смотрит на интерфейс машек, сравнивает их прошлое значение. Если обнаруживается пересечение - глядит на интерфейс торговой позиции. Если видит, что мы не в позиции - вызывает у интерфейса торгового процессора бай или селл функцию. Если видит, что позиция существует, то если позиция в нужном направлении - ничего не делаем, если в противоположном - вызываем у торгового интерфейса функцию закрытия позиции, и бай или селл.
При этом смоти: генератор не имеет доступа ни к каким переменным, ни по расчету машек, ни по получению торговой позиции, ни по открытию ордеров в МТ4 или позиций в МТ5. Дата-провайдер - знает только про машек, которые его запросили. Он их на каждом тике пересчитывает, и обновляет. Никто другой про это даже не знает. Торговый процессор - исключительно выполняет указания, которые приходят ему через интерфейс, и даже не знает, от кого они пришли. Эксперт - на каждом тике подновляет торговую позицию - и выдает ее по запрошенному интерфейсу, также, не интересуясь, кому там она нужна, и что у этого блока внутри. Все блоки - разделены, и общаются исключительно через заранее определенные интерфейсы.
Давайте конкретно и очень понятный пример.
1. на входе котир
2. на выходе команда купить/продать.
3. Вход преобразовывается в выход по пересечению двух машек.
Какие между ними ООПы и зачем?
/// применение ООП для элементарных задач (фактически весь код)
OnInit(){
Series FAST_MA=MA(...);
Series SLOW_MA=MA(...);
OnCrossUp(FAST_MA,SLOW_MA,Buy);
OnCrossDn(FAST_MA,SLOW_MA,Sell);
}
но сам по себе ООП он внутри наработанных библиотек - он делается чтобы писать легко и просто и при этом всё было отлажено. Там и интерфесы "источник котиров" и "исполнятор ордеров", "таймсерии","индикаторы" и уйма всего..Зато вот такой вот короткий код, готов к жёстким условиям реального рынка, со всеми сбоями и пакостями
лёгким движением руки можно брать произвольный котир (синтетики) или исполняться на другом инструменте..или просто командывать другим советником (а это уже преимущества ООП, сложности внутри, а в прикладной задаче требуется совсем немного усилий).
Все достаточно просто.
Есть генератор входов. Он - запрашивает у эксперта интерфейс дата-провайдера, интерфейс торговых позиций и интерфейс торгового процессора. Затем, у дата-провайдера запрашивается два интерфейса машек.
При вызове OnTick() - вызывается эта же функция у генератора входов. Генератор входов смотрит на интерфейс машек, сравнивает их прошлое значение. Если обнаруживается пересечение - глядит на интерфейс торговой позиции. Если видит, что мы не в позиции - вызывает у интерфейса торгового процессора бай или селл функцию. Если видит, что позиция существует, то если позиция в нужном направлении - ничего не делаем, если в противоположном - вызываем у торгового интерфейса функцию закрытия позиции, и бай или селл.
При этом смоти: генератор не имеет доступа ни к каким переменным, ни по расчету машек, ни по получению торговой позиции, ни по открытию ордеров в МТ4 или позиций в МТ5. Дата-провайдер - знает только про машек, которые его запросили. Он их на каждом тике пересчитывает, и обновляет. Никто другой про это даже не знает. Торговый процессор - исключительно выполняет указания, которые приходят ему через интерфейс, и даже не знает, от кого они пришли. Эксперт - на каждом тике подновляет торговую позицию - и выдает ее по запрошенному интерфейсу, также, не интересуясь, кому там она нужна, и что у этого блока внутри. Все блоки - разделены, и общаются исключительно через заранее определенные интерфейсы.
Обалдеть!
Мне вот стало интересно: есть ли еще какая-либо возможность в совремнном программировании круче запутать проблему уровня выеденного яйца?
/// применение ООП для элементарных задач (фактически весь код)
OnInit(){
Series FAST_MA=MA(...);
Series SLOW_MA=MA(...);
OnCrossUp(FAST_MA,SLOW_MA,Buy);
OnCrossDn(FAST_MA,SLOW_MA,Sell);
}
но сам по себе ООП он внутри наработанных библиотек - он делается чтобы писать легко и просто и при этом всё было отлажено. Там и интерфесы "источник котиров" и "исполнятор ордеров", "таймсерии","индикаторы" и уйма всего..Зато вот такой вот короткий код, готов к жёстким условиям реального рынка, со всеми сбоями и пакостями
лёгким движением руки можно брать произвольный котир (синтетики) или исполняться на другом инструменте..или просто командывать другим советником (а это уже преимущества ООП, сложности внутри, а в прикладной задаче требуется совсем немного усилий).
У меня OnInit() выглядит примерно также - десяток строчек...
И что?