Разговоры на завалинке о ООП - страница 6

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

Это (и все, начинающиеся с подчеркивания) -  протектед-функция класса.

Дык они ж и слиты в одну !

Функция одна - Compare(), но в ней надо произвести сравнение по передаваемому ключу. Соответственно, выбирается одна из конкретных протектед-функций. Поэтому они и защищенные (протектед), чтобы пользователь не мог к ним обратиться - обращение к ним осуществляется исключительно из Compare(), что и показывает подчеркивание.

Это тоже одно из правил оформления кода - функция, начинающаяся с подчеркивания - не предназначена для вызова пользователями, она обслуживает только определенные внутриклассовые задачи. Доступ к ней - ограничен.

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

 
Andrei:

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

Не понял... Протектед (protected) - это модификатор доступа для функции. То есть, используется протектед-функция, доступ к которой возможен только из функции класса или его потомка. Плюс символ подчеркивания лично для меня означает, что при использовании существуют некоторые неявные предположения, которые надо учитывать.

Dennis Kirichenko верно заметил - можно было бы все написать одной функцией Compare(). Но тогда бы она получилась на два десятка экранов, Обозреть ее было бы нереально, модифицировать - труднее, чем сейчас.

Я оставил в функции Compare() только селектор ключа, а код, который производит сравнение по конкретным ключам - развел по отдельным функциям. Поскольку эти функции сильно контекстно-специфические, они объявлены в protected-секции класса, для того, чтобы к ним можно было бы получить доступ исключительно из другой функции класса или потомка.  А чтобы еще и самому себе напомнить о том, что эти функции предназначены для выполнения конкретной узкой задачи внутри другой функции - я их начинаю с подчеркивания. Если в будущем я наткнусь на такую функцию - я сразу буду видеть, что существуют неявные предположения, которые необходимо учитывать при ее вызове.

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

 
George Merts:

Не понял... Протектед (protected) - это модификатор доступа для функции. То есть, используется протектед-функция, доступ к которой возможен только из функции класса или его потомка. Плюс символ подчеркивания лично для меня означает, что при использовании существуют некоторые неявные предположения, которые надо учитывать.

Ну так ограничить к функции доступ можно и классическими способами, без всякого ООП.
 
Artyom Trishkin:

Ну вот только без оскорблений личностных...

Пожалуйста почисти ветку от флуда, оставь только обучающие посты Alexey Volchanskiy
 
Andrei:
Ну так ограничить к функции доступ можно и классическими способами, без всякого ООП.

Как ?

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

 

По всей видимости, static и const (это не ООП) не нужны.

Что же касается ООП, то очень интересно, как будет выглядеть в процедурном стиле следующая, имеющая широкое практическое применение (совсем не абстрактная), функция?

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Организация цикла перебора ордеров

fxsaber, 2017.10.18 12:29

Версия без обращения к истории.
struct HISTORY_UNIT
{
  long Ticket;
  int Type;
  double Lots; 
    
  HISTORY_UNIT( void ) : Ticket(::OrderTicket()), Type(::OrderType()), Lots(::OrderLots())
  {
  }

  bool operator !=( const HISTORY_UNIT &Unit ) const
  {
    return((this.Ticket != Unit.Ticket) || (this.Type != Unit.Type) || (this.Lots != Unit.Lots));
  }
      
  bool IsChange( void )
  {
    const HISTORY_UNIT Tmp;
    const bool Res = (this != Tmp);
    
    if (Res)
      this = Tmp;
      
    return(Res);
  }
};

// Возвращает true только в случае, если с последнего вызова произошли торговые изменения
bool IsChange( void )
{
  static HISTORY_UNIT History[];  

  const int Total = OrdersTotal();  
  bool Res = (ArraySize(History) != Total);

  for (int i = 0, j = Res ? ArrayResize(History, 0, Total) : 0; i < Total; i++)      
    if (OrderSelect(i, SELECT_BY_POS))
    {
      if (Res || (Res = History[j].IsChange()))
        ArrayResize(History, j + 1, Total);
      
      j++;
    }
  
  return(Res);
}

Эта версия особенно актуальна для MT5 на VPS, т.к. MT5 работает с Историей очень медленно и затратно по вычислительным ресурсам.

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

Так насколько красивее/удобнее/читабельнее/правильнее процедурный стиль по сравнению с ООП будет в данном примере? Ну чтобы не голословить несколько страниц, а просто сравнить короткие исходники процедурный vs ООП. Прошу противников ООП показать мастер-класс. Это не страшный MT5, а старый добрый MT4.

 
Vladimir Pastushak:
Пожалуйста почисти ветку от флуда, оставь только обучающие посты Alexey Volchanskiy

уже поздно ))) тем более, я только на выхи найду время, неожиданно получилось, что сильно занят

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

 
Vladimir Pastushak:
Пожалуйста почисти ветку от флуда, оставь только обучающие посты Alexey Volchanskiy

Владимир, если за все эти годы так и не нучились, думаю уже поздно начинать;)

 
fxsaber:

По всей видимости, static и const (это не ООП) не нужны.

Что же касается ООП, то очень интересно, как будет выглядеть в процедурном стиле следующая, имеющая широкое практическое применение (совсем не абстрактная), функция?

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

Так насколько красивее/удобнее/читабельнее/правильнее процедурный стиль по сравнению с ООП будет в данном примере? Ну чтобы не голословить несколько страниц, а просто сравнить короткие исходники процедурный vs ООП. Прошу противников ООП показать мастер-класс. Это не страшный MT5, а старый добрый MT4.

Слишком уж вы замудрили даже в простом этом примере. ООП всегда проще заново написать, чем в чужом коде разбираться.... Что хотите сделать-то хоть скажите простым человеческим языком? Узнать что есть изменение в истории ордеров?
 
Vasiliy Sokolov:

Владимир, если за все эти годы так и не нучились, думаю уже поздно начинать;)


А можно уточнить, кто они и чему не научились? Модераторы не научились чистить или что-то другое )

ЗЫ: кстати, во всей ветке не увидел ни одного пожелания по освещению какой-либо темы, как всегда, обычная грызня. Так что я решил роликов на ютубе записать с нуля по устройству ООП, хоть какая-то польза будет. Все равно ветка через какое-то время окажется в ветко_отстойнике.

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