Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Да, в этих блоках есть и то и другое. Но поверьте, - они сжаты до максимума и универсальны, потому что решают широкий спектр задач.
Если всего вариантов немного то можно обойтись ифами и свичами.
А почему так никто и не решил поспорить на тему "процедурное программирование с указателями на фунции против процедурного программирование без указателей на функции"?
Если всего вариантов немного то можно обойтись ифами и свичами.
Реter Konow:
1. Дело в работе которую нужно провести чтобы сжать в коде решения огромного количества задач.
2. Дело в универсализации кода, при которой любые дополнительные синтаксические приемы и оболочки просто губительны. Это тяжелая работа, но он избавляет от всего лишнего и позволяет развиваться все время достигая новых высот.
1. Зачем проводить эту работу, если можно сделать легок и просто? Зачем делать сложно то, что можно сделать легко?
2. Если использовать ООП, то универсализация не губительна, а становится естественной ничего не обременяющей возможностью.
1. Зачем проводить эту работу, если можно сделать легок и просто? Зачем делать сложно то, что можно сделать легко?
2. Если использовать ООП, то универсализация не губительна, а становится естественной ничего не обременяющей возможностью.
Мы можем долго продолжать этот спор. На примере задачи 100 трейлингов, я показал свое отношение к такому методу решений. Считаю, что глупо поставленные задачи не должны решаться, а должны исправлятся. Если ООП помогает тем, кто слабее в умении правильно ставить и эффективно решать свои задачи, - то пусть он им и дальше помогает. Но для людей которые задачи оптимизируют еще до начала их решения, ООП может просто не понадобится.
Мы можем долго продолжать этот спор. На примере задачи 100 трейлингов, я показал свое отношение к такому методу решений. Считаю, что глупо поставленные задачи не должны решаться, а должны исправлятся. Если ООП помогает тем, кто слабее в умении правильно ставить и эффективно решать свои задачи, - то пусть он им и дальше помогает. Но для людей которые задачи оптимизируют еще до начала их решения, ООП может просто не понадобится.
Вы мало кодили (наверно), ООП это как глоток воздуха.
В основном люди кодят не для интереса и не с целью саморазвития, а работа у них такая, и на этой работе важен результат.
По удобству не стоит рядом, но по возможностям обеспечения быстродействия - можно обойтись одними указателями.
А удобство - понятие относительное.
Дмитрий, конечно использоваие ООП немного снижает быстродействие. Но это доли процента.
Зато как ООП повышает производительность программера!
Вот небольшой пример из одного моего проекта, он урезан для быстроты восприятия, на самом деле, там еще куча всего заюзано
Для примера, берем .NET, там же все API состоит из классов.
Мне парадигма .NET очень нравится, кстати, есть отличный терминал cAlgo, там можно напрямую писать в Visuaд Studio на C#
Дмитрий, конечно использоваие ООП немного снижает быстродействие. Но это доли процента.
Если малое количество вариантов,то снизит, но если очень много, будет преимущество.
Самое важное, в ООП от количества вариантов не зависит быстродействие. А в процедурном программировании над головой потолок.
Ну, наворотили...
Да ясно, что любая задача может быть решена как в ООП-стиле, с выделением интерфейсов, построением иерархии наследования, объявлением виртуальных функций, так и в чисто процедурном стиле - можно даже все воткнуть в одну огромную функцию.
Вопрос - в удобстве и эффективности поддержки.
В МТ - наиболее ООП-подходящим местом является ордерная система. Лично у меня есть виртуальные интерфейсы "позиции" и "компоненты позиции". "Позиция" - это набор ордеров в МТ4 или набор позиций МТ5. "Компонента позиции" - это отдельный ордер или отдельная МТ5-позиция (хеджевая или неттинговая).
Вот реальный файл интерфейса (Реter Konow, можешь оценить количество комментариев по сравнению с объемом кода, причем, я периодически их туда добавляю, когда сталкиваюсь с тем, что некоторые тонкости не помню. Скажем, я регулярно забываю, какие реальные объекты представляют из себя "компоненту позиции". Мне это просто не надо помнить - эксперт работает с компонентами согласно интерфейсу, а что там в реальности стоит за этим интерфейсом - неважно. Но, при модификации к этому приходится возвращаться - поэтому мне первый комментарий в этом файле очень часто требуется):
Файл интерфейса торговой компоненты следующий (выше я его приводил уже, но повторю:
Согласно этим интерфейсам - у меня реализована и ордерная система МТ4, и МТ5, как для реальных, так и для исторических ордеров.
Эксперт, запросив позицию - получает данный интерфейс, и ему совершенно не надо учитывать разницу в работе с ордерами МТ4 и МТ5. Причем, если будет добавлен новый тип ордера, или изменится порядок работы с ними - для эксперта - ничего не изменится, добавится только класс нового типа ордера, который будет также поддерживать данный интерфейс.
Система показала себя очень даже разумной, когда были введены счета с хеджированием. Эксперты - совершенно от этого не изменились.
Реter Konow, как у тебя решается вопрос с различием типов ордеров в МТ4 и МТ5 ?
Если будет введен новый тип счета (вдобавок к хеджевому и неттинговому) - какие изменения потребуется вносить, и в одном ли месте ?
На мой взгляд, действительно, если ты помнишь весь свой код до буквы, и легко можешь сказать, почему написана та или иная строка в твоем коде год назад - то, и правда, все эти ООП-навороты - только лишние никому не нужные телодвижения.
ООП необходимо именно тогда, когда ты при модификации кода помнишь далеко не все - ООП позволяет изолировать блоки друг от друга ограничить набор сущностей, доступных в каждый момент конкретному месту программы.
Ну, наворотили...
1. Да ясно, что любая задача может быть решена как в ООП-стиле, с выделением интерфейсов, построением иерархии наследования, объявлением виртуальных функций, так и в чисто процедурном стиле - можно даже все воткнуть в одну огромную функцию.
Вопрос - в удобстве и эффективности поддержки.
2. В МТ - наиболее ООП-подходящим местом является ордерная система. Лично у меня есть виртуальные интерфейсы "позиции" и "компоненты позиции". "Позиция" - это набор ордеров в МТ4 или набор позиций МТ5. "Компонента позиции" - это отдельный ордер или отдельная МТ5-позиция (хеджевая или неттинговая).
3. Вот реальный файл интерфейса (Реter Konow, можешь оценить количество комментариев по сравнению с объемом кода, причем, я периодически их туда добавляю, когда сталкиваюсь с тем, что некоторые тонкости не помню. Скажем, я регулярно забываю, какие реальные объекты представляют из себя "компоненту позиции". Мне это просто не надо помнить - эксперт работает с компонентами согласно интерфейсу, а что там в реальности стоит за этим интерфейсом - неважно. Но, при модификации к этому приходится возвращаться - поэтому мне первый комментарий в этом файле очень часто требуется):
Файл интерфейса торговой компоненты следующий (выше я его приводил уже, но повторю:
Согласно этим интерфейсам - у меня реализована и ордерная система МТ4, и МТ5, как для реальных, так и для исторических ордеров.
Эксперт, запросив позицию - получает данный интерфейс, и ему совершенно не надо учитывать разницу в работе с ордерами МТ4 и МТ5. Причем, если будет добавлен новый тип ордера, или изменится порядок работы с ними - для эксперта - ничего не изменится, добавится только класс нового типа ордера, который будет также поддерживать данный интерфейс.
Система показала себя очень даже разумной, когда были введены счета с хеджированием. Эксперты - совершенно от этого не изменились.
4. Реter Konow, как у тебя решается вопрос с различием типов ордеров в МТ4 и МТ5 ?
Если будет введен новый тип счета (вдобавок к хеджевому и неттинговому) - какие изменения потребуется вносить, и в одном ли месте ?
На мой взгляд, действительно, если ты помнишь весь свой код до буквы, и легко можешь сказать, почему написана та или иная строка в твоем коде год назад - то, и правда, все эти ООП-навороты - только лишние никому не нужные телодвижения.
ООП необходимо именно тогда, когда ты при модификации кода помнишь далеко не все - ООП позволяет изолировать блоки друг от друга ограничить набор сущностей, доступных в каждый момент конкретному месту программы.
1. Полностью согласен. Разница только в эффективности решения задач тем или иным способом.
2. С ордерной системой работал мало, и технических проблем ее построения сейчас не вижу. Возможно они есть, но нужна конкретная задача, и тогда станет ясно насколько эффективно я могу решить ее без ООП.
3. Приведенный пример кода (с моей точки зрения) просто ужасен с точки зрения читабельности. Не удивительно, что требуется столько комментариев и почему ты забываешь его содержание. Прости, но это мое субъективное первое впечатление. Просто жуть какая то.
Вот пример читабельности моего кода - функция определяющая цвет детали элемента управления:
Как видишь, комментарии здесь почти не нужны. В таком стиле у меня написан весь код. Поэтому я его отлично знаю и помню, независимо от того, какой размер он имеет.
По моему мнению, в твоей системе решения задач есть какой то деффект. Сама задача должна быть кристальнно ясной и четкой, а следовательно ее решение тоже. Если решение мутное и определяемое словами "Система показала себя очень даже разумной" (какая может быть разумность в 270 кб-ах кода?!), то это означает, что автор приблизительно понимает как его система работает. И понять до конца ему мешают страшные навороты синстксиса и лишние в решении сущности.
Для эффективности решения лишние сущности нужно отсекать, а проблему видить идеально ясно.