Вопрос к разработчикам. А почему бы не сделать клиент на Java. Зачем изобретать велосипед? - страница 3

Поправлюсь: я не против ООП вообще, мне на нем очень много чего доводилось делать и для себя, и по заказу, и в целом это вещь хорошая и удобная. Я против пальбы из пушек по воробьям. Думаю, в МТ ООП ни к чему. Кроме путаницы, лишних глюков и тьмы лишних вопросов, из этого начинания больше ничего не выйдет. Кроме того, я против ООП в мелкомягком исполнении. Повозившись изрядное время с хваленым .NET (причем возился далеко не всегда по-джентльменски) и посмотрев массу мнений разработчиков ПО со всего мира, окончательно убедился в том, что эта вкусная конфетка служит только для сохранения мировой мелкомягкой монополии в области ПО для персональных машин. Не буду входить в детали, скажу лишь, что если так пойдет и дальше, образно говоря, пользователи "с покупкой каждой новой пары брюк будут вынуждены покупать новый утюг, потому что глажка новых брюк старым утюгом вызовет illegal operation & version conflict" (подсмотрено). Кстати, по этой же причине все чаще подумываю о переходе на Линукс. Хватит уже кормить дармоеда Б.Г. со всей его оравой.
А что насчет второго вопроса? Кому-нибудь еще не кажется это странным?

.NET не плох... просто меня устраивает MQL4 и мне не нужны ни ява, ни .net.

Зачем mql ООП? Чего не хватает вам? Я думаю и без него можно справиться и обойтись.
2 bstone: Интересно. Это почему же программы написанные на ООП менее подвержены ошибкам?
Я думаю количество ошибок во многом зависит от программиста, ну и плюс ещё от ошибок в используемых
библиотеках. Тем более ООП программирование посложнее процедурного.
Мое ИМХО, больше вероятность совершить ошибку в ООП программировани, чем в процедурном.
Хотя конечно все зависит от квалификации программиста.

2natlam: насчет C# те же проблемы что и java.

Luptator 03.04.2007 18:18
2 bstone: Интересно. Это почему же программы написанные на ООП менее подвержены ошибкам?

Потому что:

1) Когда я пишу, используя ООП, я оперирую абстракциями, отражающими предметную область, а не примитивами языка.
2) ООП повышает читабельность кода, избавляет его от громоздких конструкций.
3) ООП позволяет намного проще создавать код, который можно использовать повторно без дополнительной адаптации.
4) ООП позволяет удобно работать с динамическими структурами данных (списки, множества, векторы и т.п.).
5) ООП позволяет легко расширять функциональность за счет локализации изменений внутри отдельных абстракций.
6) Ну и добавьте сюда все другие преимущества, которые дают фундаментальные принципы ООП: полиморфизм, наследование, инкапсуляция.

Если вам не понятно, как пункты (1)-(5) снижают число ошибок в коде, то вы имеете очень скудное представление об ООП в частности и о программировании в целом. Однако не отчаивайтесь. Мой многолетний опыт работы показывает, что большинство людей, считающих сбея хорошими программистами, слабо разбираются в таких вопросах. При наличии определенных интеллектуальных задатков это все приходит с опытом.

Хорошо, что разработчики в глобальных вопросах игнорируют пожелания трудящихся и следуют собственному видению продукта. 

Можно просто дабавить структуры в MQL типа
struct MyStructure {
int i;
string str;
double dVar;
}
Также возможность создавать массивы структур и
передавать переменную структуру и массив структур в DLL так же стоит предусмотреть.
Классы с моей точки зрения не нужны. Если уж добавлять возможнсоть классов то сделать возможным включать в один модуль другой не текст а декларацию ну например как в дельфи
или хотябы как в си более сложный вариант.
например создаём модуль и в нем указываем что использовать все декларации в другом модуле. Например как в дельфи
uses MyUnit;
или unclude MyModule либо import MyClass
А сейчас тело одной библиотеки просто как есть добавляется в другой и это компилируется. Не удобно это

Прочитайте внимательно руководство по MQL. Вы просто не умеете пользоваться библиотеками :) Нормальные библиотеки как раз компилируются отдельно, а включается только небольшой файл, декларирующий публикуемые библиотекой функции. Если вы делаете по другому, это еще не значит, что нельзя делать правильно :)

Вы не в теме :) Как раз разработчики достаточно умны, чтобы прислушиваться к трудящимся и игнорировать пожелания "нетрудящихся" ('Очень серьёздный вопрос.'):

Renat 04.02.2007 16:12
Будет MQL5, полностью совместимый с существующим кодом MQL4. Сейчас пишется новый высокоэффективный компилятор MQL5 со структурами и классами.

2 bstone. Хорошо. Поверю твоему многолетнему опыту.

Если реализовывать ООП и другие возможности, то зачем тогда нужен mql,
не проще ли будет тогда реализовать эксперты и индикаторы в виде dll-плагинов
к Метатрейдеру? Тогда можно будет писать dll-ки на любом языке.
Хотя кто знает,что лучше? Опять тут играет роль скорость выполнения
и другие факторы.

Наверно разработчики, рассматривали разные варианты.
Видимо сочли текущую реализацию наиболее подходящей.

Проще, но тогда встанет вопрос с безопасностью кода в dll-ках. При отключении внешних dll, терминал/сервер может гарантировать безопасность кода эксперта, т.к. его возможности строго ограничены языком MQL. Больше возможностей по контролю работы эксперта - например, сейчас его можно остановить нажатием кнопки в любой момент, с внешней dll такой фокус пройдет не всегда.

Еще у текущего подхода есть преимущество в отношении многоплатформенности. Т.е. написал эксперта на MQL и он будет работать на всех платформах, на которых будет работать терминал (Windows,*nix, КПК, и т.п.).