Оверхед для ООП - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Разумеется за красивости ООП надо платить ресурсами и большими расходами времени по отладке. ООП имеет смысл лишь как удобная обертка текста либо при минимальном использовании при инициализации среды исполнения... По сути ООП это была чисто маркетинговая штука от Микрософота для повышения расходов на рабочие часы программистов и стимулировании покупки более продвинутого оборудования. Причем сами они не дураки и весь софт пишут на Си и ассемблере.
ну и бредятина
всем известно, что программисты MS пишут сразу в машинных кодах
у каждого программиста на столе лежит книжица с машинными кодами процессора и они прям сходу фигачат коды на перфокарты
а Билл Гейтс умеет компилировать в голове операционную систему ))
ну и бредятина
всем известно, что программисты MS пишут сразу в машинных кодах
Клоунада ваша не совсем понятна, известно что для повышения быстродействия кода используются вставки на ассемблере...
Могу предположить, что в терминале ООП используется по минимуму либо вообще не используется так как без огромных внешних библиотек как в дотнете сложно получить такие компактные файлы...
А по сути сказанного есть осмысленные аргументы?
Есть. Алексей, и в самом деле, просто эмоционально отреагировал. А по сути возражения следующие.
ООП - очень помогает, когда требуется поддержка сколь-нибудь комплексного кода.
Безусловно, для индикатора-МА применять все ООП-ухищрения не имеет смысла. Хотя, когда базовые классы - написаны - даже для МАшки - все равно ООП-подход, по крайней мере, не хуже обычного, процедурного подхода.
Главное преимущество ООП раскрывается при поддержке развитых структур объектов. Когда за счет инкапсуляции - не требуется каждый раз разбираться во всех нюансах перегружаемых функций. Когда за счет полиморфизма - значительно повышается повторное использование кода.
Сама суть ООП ближе к реальному миру, где любые объекты всегда связаны со своими свойствами, и имеют определенные правила взаимодействия с окружающим миром.
Про "повышение расходов на рабочие часы" - это не так. Безусловно, при проектировании системы в ООП-стиле работы требуется несколько больше, чем в процедурно-ориентированном подходе. Однако, эти дополнительные затраты с лихвой компенсируются удобством поддержки и изменения написанного кода.
Лично я совсем мелкие "наколенкенаписанные" индикаторы - пишу без всяких объектов. Однако, когда требуется что-то чуть большее (хотя бы кроссплатформенность) - я всегда применяю ООП-стиль и имеющиеся наработки в библиотеках объектов.
Клоунада ваша не совсем понятна, известно что для повышения быстродействия кода используются вставки на ассемблере...
Могу предположить, что в терминале ООП используется по минимуму либо вообще не используется так как без огромных внешних библиотек как в дотнете сложно получить такие компактные файлы...
1. ООП - очень помогает, когда требуется поддержка сколь-нибудь комплексного кода.
2. Безусловно, для индикатора-МА применять все ООП-ухищрения не имеет смысла. Хотя, когда базовые классы - написаны - даже для МАшки - все равно ООП-подход, по крайней мере, не хуже обычного, процедурного подхода.
3. Главное преимущество ООП раскрывается при поддержке развитых структур объектов.
1. А например? Громкие лозунги это хорошо, но непонятно о чем конкретно речь...
2. Уже было сказано, что как обертка текста ООП хорошо помогает, но и то потому что это не было доведено до ума в процедурном программировании.
3. А зачем плодить эти "развитые структуры"? Для быстродействия кода это будет убийственно, да и не факт что баги в нем ловить будет легче и быстрее по времени.
Современные компиляторы оптимизируют в разы лучше, чем средний и даже хороший программист.
Может быть какие простые и тривиальные вещи и могут, но только потому, что люди сидели и вручную написали алгоритм, но если что-то нестандартное то далеко не факт, особенно если там ООПешные навороты встречаются.
В драйверах да, применяют ассебблер, но не из-за быстродействия, просто проще работать с аппаратурой.,
Ну так люди же не дураки - зачем им что-то сложное и запутанное, которое к тому же еще и медленное?
1. А например? Громкие лозунги это хорошо, но непонятно о чем конкретно речь...
2. Уже было сказано, что как обертка текста ООП хорошо помогает, но и то потому что это не было доведено до ума в процедурном программировании.
3. А зачем плодить эти "развитые структуры"? Для быстродействия кода это будет убийственно, да и не факт что баги в нем ловить будет легче и быстрее по времени.
1. Например, вам нужен массив объектов. Это вполне можно сделать как в процедурном виде, так и на основе CArrayObj и СОbject. Проблемы начнутся тогда, когда надо будет изменить поведение, скажем, при добавлении или удалении объектов или их сортировке. В ООП - поддержка собственно массива указателей, и работа с ним - заключена в базовых объектах. Изменение объектов-наследников, которые реально содержатся в массиве - ничего не затрагивает. При процедурном же стиле - изменение реальных объектов, которые содержатся в массиве - как правило, затрагивает гораздо больше мест, как минимум, потому, что надо учитывать изменение размера объектов. Что гораздо легче приведет к ошибкам.
Кросплатформенность - также гораздо удобнее организовывать в ООП-стиле. Когда по запросу, скажем, торговой позиции - мы получаем интерфейс, и нам не важно, на какой платформе мы работаем - интерфейс предлагает виртуальные функции, по которым можно получить все данные по всем ордерам (для МТ4) или позициям (МТ5), причем, с точки зрения эксперта - тут вобще никакой разницы нет. Эксперту совершенно не требуется знать, на какой платформе он работает.
2. Ну так ведь "доведение до ума в процедурном программировании" - это и есть "написание объектов-процедур", то есть создание неких связей между данными и процедурами, которые в ООП представляют объекты.
3. А затем, что у нас существует, скажем, ряд видов ордеров, в которых масса общего. Разумно сделать объект COrderInfo - который будет базовым, а его наследники - будут представлять различные виды ордеров. При этом торговый процессор (у меня класс CTradeProcessor) - будет автоматом поддерживать именно тот ордер, который ему передали, именно теми процедурами, которые нужны для обработки этого ордера.
Ловить баги легче там, где наименьшее количество перекрестных связей. Что как раз и обеспечивается инкапсуляцией и полиморфизмом. Мы запрашиваем интерфейс торговой позиции (CTradePositionI) - и все связи с реальными классами, представляющими эту позицию (CMT4PositionInfo,CMT5PositionInfo) - осуществляются исключительно через этот интерфейс, что как раз и способствует более легкому устранению ошибок, чем если бы мы работали непосредственно с реальными функциями, возвращающими данные торговой позиции.