Будет ли востребовано ООП в MQL5? - страница 2

Позволю аналогию: первый взял нож и вырезал филигранную фигурку, а второй - отхватил себе полпальца этим же ножом. К чему это? Любым инструментом можно создать и "конфетку", и полную бездарь. Все зависит от програмера, ремесленник он или имеет искорку таланта. Это так, отступление, а по сути - если вам ближе ФОП, ну и используйте его далее.

Создавая сабж, я хотел увидеть аргументы в пользу ООП в проектах для целей МТ. Может, в силу своей невежества - я не кокетничаю - их не видел. Не вижу и сейчас.

Давайте подытожу ваши посты (кстати, всем спасибо):

1. Удобство и скорость реализации проекта.

Это какого же объема должен быть проект, чтобы это удобство почувствовать? Покажите мне то, что было создано для 4-ки, что было бы удобнее сделать с ООП. Нет ответа.

2. Сопровождение, модернизация.

Опять же - размер проекта.

3. 5-ка быстрее, потому пох как программировать.

Ну, это вообще не аргумент. Без каментов.

3. Криворукость как причина замедления ООП.

Ага. Обычно программы я пишу руками, а вот если хочу ООП, то поворачиваюсь к компу задом. ))) Нет. ООП объективно медленнее будет аналогичной по алгоритму процедурной.

------------

(пожимая плечами) Поймите, я не против ООП, я просто хотел выяснить для себя, что это может мне дать в задачах для МТ - в создании индюков, скриптов, советников.

ок. Хэлп по 5-му есть. Кто может привести пример простенького индюка из старндартной поставки МТ4 написанного с использованием ООП на 5-ке?. Там и видно будет. Там и задержки можно оценить на глазок по тексту, читаемость программы и пр.

1. ООП - очень удобно для тех, кто понимает основные принципы. Это чувствуется даже в простейших приложениях. Любое приложение удобней сделать с ООП.

2. Размер проекта - не помеха, если в нем не сложно разобраться. А если программа объектно-ориентирована, разобраться в ней не составляет особого труда. Пример - терминал SaxoBank. Написан на C# - объектно-ориентированный язык. В каждой dll порядка 20 000 строк кода. Если бы не ООП, разобраться в таком объеме информации, а тем более модернизировать было бы практически нереально.

В 5-ке не с ООП проблема. Там вообще пока непонятно, как крупные прректы реализовывать из тех, что были реализованы в 4-ке. Работа с графическими объектами сделана "раком". Разработчики обещали улучшить, но... пока улучшения не чувствуется. Игрушки стало возможно программировать.

Наверное ZUP от nen'а будет неплохим примером. Там много чего наворочено. Одна только масса исходника внушает уважение (368Kb v82), не говоря уже о содержании.

В 5-ке процедурное программирование никто не отменял. Не нравится ооп - пиши программы по старому. Но с графическими индикаторами создали огромную проблему. Их уже будет очень сложно реализовывать. И для программистов. И тем, кто вручную торгует, применяя графические индикаторы. Придется простым трейдерам - не программистам - переучиваться. А это не все смогут нормально сделать.

Создается ощущение, что в MQ считают что существует торговля только с помощью роботов-автоматов. И 5-ка заточена именно на роботов. Ручную торговлю решили уничтожить как класс.

У них уже в основе не ООП (хотя абсолютное ООП практически не удобно). Нужно было изначально создавать абстрактные классы и доходить с помощью наследование и полиморфизма до реальных объектов. Например, базовый абстрактный класс для пользовательских индикаторов с абстрактыми методами и свойствами. Короче строить иерархическое дерево классов: свое дерево и для графических объектов, для работы со счетом, для графиков и доступа к тайм-сериям и т.д. А на предопределенные процедуры и функции оставить только элементарную рутину требующую быстродействия. Тогда можно было бы расширять возможности платформы с любого уровня абстракции, что значительно сократило бы код, улучшило читаемость и простоту его понимания другими программерами. А в МТ5 уже реализованы довольно сложные вещи на уровне процедур (фактически вся готовая к использованию платформа) и я не увидел возможности доступа по указателям хотя бы к дескрипторам создаваемых внутренних структур, что весьма ограничит возможности (судя по хелпу). Да и вообще необходимость ООП под вопросом, при такой реализации можно было ограничится структурами и динамическим размещением. ООП должно быть поддержено снизу разветвленной иерархией классов. имха

Нужно 1-3 года программирования - для осознания того, что программы программистами НЕ ПИШУТСЯ, а ЧИТАЮТСЯ.

Ещё 1-2 года надо для осознания того, что программы пишутся не для компьютера, а для человека (в частности для себя).

Потом нужно 1-2 года, чтобы заметить, что ООП и С++ противоречит порядку мышления гуманоидов и методу построения человеческих языков.

Ещё 1-2 года надо для изучения чужых сырцов и осознания того, что самые лучшие и надёжные программы написаны на классическом Це.

Ну а после этого достаточно прочитать интервью Дейкстры про то, что С++ и ООП вызывают у него желудочные боли.

А после этого (итого 4-9 лет) вопросов "об ООП" вообще не возникает, а подобные дискуссии вызывают только снисходительную улыбку.

Сочувствую.