Вложенные классы и справка по языку MQL.

Новый комментарий
 

Собственно потребовалось сделать в MT4. Сначала прошёлся поиском по справке комбинациями "вложенный", "внутренний" и т.д. Потом обратился к яндексу с сочетаниями вида "MQL вложенные классы/ MQL внутренние классы". Эффекту 0. В итоге загуглил "C++ вложенные классы" и за пару минут сделал что мне было нужно / проверил результат работы.

Я конечно понимаю, что Subj не вещь первой необходимости в наборе программиста, но раз MQL поддерживает эту возможность, неплохо было бы об этом упомянуть в справке по языку (и 4, и 5). И в том числе о вариантах и нюансах взаимодействия внешнего и внутреннего класса. Или, предполагается, что если нужно чуть глубже копнуть в ООП на MQL нужно обращаться к книжкам на C++? Так как например мои знания/практика ООП из  Java / .Net в деталях далеко не всегда применимы к  несколько архаичной реализации ООП в C++/MQL и некоторые вещи вызывают вопросы. А с другой стороны и MQL далеко не всё из плюсов поддерживает (особенно последних стандартов) и где гарантия, что например реализация того же вложенного класса в MQL и C++ совпадает в деталях (а дьявол всегда кроется в деталях) на все 100%?

 
Ув. админы, кто перенёс тему из "Общего обсуждения". Тема была размещена именно там вполне осознанно, так как в равной степени касается хэлпа как 4, так и MT 5... Имхо, не совсем корректно загонять ее в подвал по MT4 и терять часть обсуждения.
 
Это обычно называется наследованием: https://www.mql5.com/ru/docs/basis/oop/inheritance
Документация по MQL5: Основы языка / Объектно-ориентированное программирование / Наследование
Документация по MQL5: Основы языка / Объектно-ориентированное программирование / Наследование
  • www.mql5.com
Особенностью ООП является поощрение повторного использования кода при помощи механизма наследования. Новый класс производится от существующего, называемого базовым классом. Производный класс использует члены базового класса, но может также изменять и дополнять их. Многие типы представляют собой вариации на темы существующих. Часто бывает...
 
Renat Fatkhullin:
Это обычно называется наследованием: https://www.mql5.com/ru/docs/basis/oop/inheritance

Ренат, обычно это называется вложенный или внутренний класс, вы уж всех то тут за домохозяек не считайте пожалуйста... Основы ООП я слава Богу знаю уже больше 25 лет, но реализация ООП в C++/MQL несколько отличается от того что сейчас принято в более новых "Си-образных" языках: Java/C#/D. И тот опыт далеко не всегда применим в MQL.

class OuterClass
  {
private:
   class InnerClass
     {
   public:
      void Bar()
        {
         // Some code
        }
     };
   InnerClass        _Inner;
public:
   void Foo()
     {
      this._Inner.Bar();
     }
  };

Это в общем то достаточно тривиальные вещи, но подозреваю что реализация не полностью совпадает с Java/C# или D. В каком разделе справки по MQL можно об этом подробно прочитать? В справке по C++?

 
h.i.a:

Ренат, обычно это называется вложенный или внутренний класс, вы уж всех то тут за домохозяек не считайте пожалуйста... Основы ООП я слава Богу знаю уже больше 25 лет, но реализация ООП в C++/MQL несколько отличается от того что сейчас принято в более новых "Си-образных" языках: Java/C#/D. И тот опыт далеко не всегда применим в MQL.

Это в общем то достаточно тривиальные вещи, но подозреваю что реализация не полностью совпадает с Java/C# или D. В каком разделе справки по MQL можно об этом подробно прочитать? В справке по C++?

Почитайте в документации раздел "Объектно-ориентированное программирование", пожалуйста.

Области видимости описаны тут, структуры/классы/интерфейсы тут (где есть ваш случай). Использовать можете как и в других языках.

Определения внутри локальных областей видимости у нас поддерживаются штатно.

 

Хотя справочник MQL5 занимает 5 600 страниц, у нас нет задачи и обязанности обучать основам программирования и покрывать мельчайшие подробности языковых конструкций.

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

Если вы хотите начать свою работу тут с критики и требований, то это не самый лучший вариант.

 
Renat Fatkhullin:

Хотя справочник MQL5 занимает 5 600 страниц, у нас нет задачи и обязанности обучать основам программирования и покрывать мельчайшие подробности языковых конструкций.

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

Если вы хотите начать свою работу тут с критики и требований, то это не самый лучший вариант.

Ренат, я всего лишь высказал удивление, так как первый раз сталкиваюсь с неполной спецификацией языка в официальном хэлпе. 

Для меня нет никакой сложности найти и решить свой вопрос самостоятельно (что собственно и было сделано до создания этого топика), но несколько странно это делать в справке по другому языку программирования, с учётом того что MQL не является точной копией C++.

Ранее я уже сталкивался с некоторыми подобными нюансами, не отражёнными в справке, например сочетанию const-метода и virtual, также не очевидному для меня как не C++ программиста.

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

 
А смысл в написании класса внутри класса?  Внутренний все равно имеет глобальную видимость. За то читаемость кода снижается. 
 
Dmitry Fedoseev:
А смысл в написании класса внутри класса?  Внутренний все равно имеет глобальную видимость. За то читаемость кода снижается. 

За всю Одессу не скажу, но в моем конкретном случае смысл в разделении сущности на некоторое количество внутренних изолированных между собой и "внешним миром" составных частей, используемых только в пределах внешнего класса. При этом ни внешних вызовов к этим внутренним частям, ни повторное использование где-либо еще не предполагается. Как уже писал в первом посте, вещь не первой необходимости, но иногда именно такая декомпозиция класса является наиболее красивым и логичным решением.

Вещь в ООП весьма стандартная (и обычно прописанная в спецификации к языку):

https://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/classes-and-structs/nested-types

https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html

 

Проверил Ваше утверждение про "глобальную видимость". При попытке  создать объект на основе внутреннего класса в стороннем внешнем классе и обратиться к его методу "Cannot access private member function" - всё как надо отрабатывает.

По мне, чем больше инструментов по обеспечению дополнительных уровней изоляции между частями программы предоставляется средствами языка, тем лучше. Для индикатора из 100 строчек это не важно, а когда проект состоит из сотен или тысяч файлов, то тут уже совсем другой разговор начинается. И если когда-нибудь завезут в MQL модули/пакеты или локальные функции как в C# 7, я только рад буду.

 
h.i.a:

Проверил Ваше утверждение про "глобальную видимость". При попытке  создать объект на основе внутреннего класса в стороннем внешнем классе "Cannot access private member function" - всё как надо отрабатывает.

По мне, чем больше инструментов по обеспечению дополнительных уровней изоляции между частями программы предоставляется средствами языка, тем лучше. Для индикатора из 100 строчек это не важно, а когда проект состоит из сотен или тысяч файлов, то тут уже совсем другой разговор начинается. И если когда-нибудь завезут в MQL модули/пакеты или локальные функции как в C# 7, я только рад буду.

А как вы проверили видимость?

Я вот так:

class OuterClass
  {
private:
   class InnerClass
     {
   public:
      void Bar()
        {
         // Some code
        }
     };
   
public:
   void Foo()
     {
      //this._Inner.Bar();
     }
  };
  
  
InnerClass        _Inner;

Компилируется. То есть класс InnerClass видим за пределами класса OuterClass. Нет никакого выигрыша, кроме усложнения читаемости от вложенности.

12
Новый комментарий