Справка по языку MQL5 - страница 35
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Структуры и классы
Не помешает также пояснить, какова по умолчанию видимость не только элементов обьявленного класса, но и его самого в целом (public), и можно ли её изменить. Также, "видят" ли друг друга классы, объявленные в MQL5 библиотеках и include файлах.
Наследование
Лично мне не понятно, чем руководствовались разработчики при допущении потенциальной сумятицы и плохого стиля разработок в плане OOП - подрыв наследования при использовании слов protected или private:
В этом контексте IMHO просто необходимо упомянуть, какой стиль наследования используется по умолчанию, например, выделив слово public:
Виртуальные функции
Необходимо пояснить что происходит при попытке создания оператором new (например, базового) класса, элемент(ы) которого описаны (как виртуальные функции), но не имеют реализации, т.е. абстрактны. Также, возможна ли декларация абстрактного конструктора.
Ответ разработчиков:
MQL5 не поддерживает "чисто виртуальные" (pure virtual) функции. Т.е. виртуальные функции, которые не имеют реализации (в с++ объявляются как virtual <type> Method(<params>)=NULL. У нас, объявляемая virtual функция ОБЯЗАТЕЛЬНО должна иметь тело, даже если не предполагается её вызов.
А следовательно на сегодняшний день в MQL5 нет понятия абстрактных классов.
Ответ разработчиков:
Ну а зачем тогда разрешать описание тела вне блока класса, это абстракция а ля MQL5 что ли?
Безобразие, конечно, допустимо... если описание тела можно воткнуть в другой файл с подключением через #include :) Так можно хулиганить?
Второе - а конструктор и деструктор виртуальны по умолчанию или как, из описания не ясно?
Типы событий графика
У этой пары констант либо некорректные названия, либо их описание, скорее всего оба :)
CHARTEVENT_MIN и CHARTEVENT_MAX по аналогии с например CHART_FIXED_MAX и CHART_FIXED_MIN, или _FIRST и _LAST, но уж никак не maximal last value, тогда где minimal last value?
CHARTEVENT_CUSTOM
Minimal сustom event value
CHARTEVENT_CUSTOM_LAST
Maximal last custom event value
Ну а зачем тогда разрешать описание тела вне блока класса, это абстракция а ля MQL5 что ли?
Безобразие, конечно, допустимо... если описание тела можно воткнуть в другой файл с подключением через #include :) Так можно хулиганить?
Второе - а конструктор и деструктор виртуальны по умолчанию или как, из описания не ясно?
1) Описание тела от класса никак не способствует абстракции
2) Да, так хулиганить можно
3) Виртуального конструктора нет, деструктор виртуален по умолчанию.
1) Описание тела от класса никак не способствует абстракции
2) Да, так хулиганить можно
3) Виртуального конструктора нет, деструктор виртуален по умолчанию.
1. В рамках ООП - естественно нет. Но зато способствует разбрызгиванию объектного кода; ни Ява, ни C# такого буйства не разрешают. Спишем как издержки производства от C/C++ :)
2. А вот это уже делают не от хорошей жизни. Отсутствие в языке абстрактных классов или интерфейсов делает ООП оччень даже размытой и толкает на дурной дезайн софтины :((
3. Значит, объявив виртуал конструктору, компилятор завопит?
pisara писал(а) >>
1. В рамках ООП - естественно нет. Но зато способствует разбрызгиванию объектного кода; ни Ява, ни C# такого буйства не разрешают
И это типо плюс ???
2. А вот это уже делают не от хорошей жизни. Отсутствие в языке абстрактных классов или интерфейсов делает ООП оччень даже размытой и толкает на дурной дезайн софтины :((
Плохому танцору яйцы мешают.
И это типо плюс ???
Разбрызгивание кода класса противоречит одному из основных принципов ООП - инкапсуляции объектного кода, значит, ухудшает качество софта, в котором ООП хотят использовать.
Плохому танцору яйцы мешают.
Брейк к танцам не причисляю.
2. отделение объявления от реализации позволяет сделать код более читабельным, более логически организованным.
1. распределение кода улучшает инкапсуляцию, т.к. позволяет предельно локализовать используемые данные.
2. отделение объявления от реализации позволяет сделать код более читабельным, более логически организованным.
1. мы о том же самом распределении говорим? капсула конкретного класса на конкретной ступеньке иерархии должна содержать в себе всю "черепаху", а не только её голову, лапы или панцирь.
Локализация вовнутрь капсулы класса. Ява и, позже построенный на её опыте острый Си, писАлись разными деятелями, причём все они плясали от имеющейся базы и опыта C/C++, навряд ли они были наивны или глупы.
2. не, капсула, объект, класс, животное создание, возьми хоть что - не надо их резать и разрывать, прикрываясь логикой Буля, историческим наследием Си и т.п.
3. грамотный объектный код содержит от 2 до 5 строк в теле метода/функции. Если же не охота вдаваться в нюансы ООП - пиши на здоровье "пахучие" расколбасы процедур с бесконечными вложенными и, порой, практически повторяющимися кусками кода и циклами if (!working) ... каждому своё, ведь и разработчики MQL5 не сильно настаивают...