ООП vs процедурное программирование - страница 6

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

И как собираетесь делать, что бы трейлинг приспосабливался к разным параметрам?

Давайте попробуем на какой то конкретной задаче. Если есть, предоставьте пожалуйста.
 
Реter Konow:
Желательно привести к конкретной задаче. Такое описание не очень понятно. В моей практике алгоритм не меняется от изменения внешних параметров. Он заранее делается  универсальным для любых значений этих параметров. Поэтому, не очень ясно, что Вы имеете ввиду. Опишите на конкретном примере.
class Ордер
{
  public: int SELL;

  Ордер(void) // Конструктор имеет то же имя, что и класс. Выполняется при инициализации переменной класса
  {
    SELL=0;
    int k=OrdersHistoryTotal()-1;
    for(; k>=0; k--)
    {
      if(!OrderSelect(k, SELECT_BY_POS, MODE_HISTORY)) continue;
      if(OrderType()==OP_SELL)SELL++;
    }
  }
}x;

void OnStart()
{
  Alert(x.SELL);
}

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

 
Реter Konow:
Давайте попробуем на какой то конкретной задаче. Если есть, предоставьте пожалуйста.

Конкретная задача. Заказчик заказ эксперта по двум МА, что бы в него были вставлены все имеющиеся в кодабазе варианты трейлинга, но и что бы в тестере не тормозило.

Да и еще с перспективой по доработке новыми вариантами трейлинга в будущем (не дорого).

 
STARIJ:

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

Не понимаю, почему не сделать функцию "int Количество_ордеров()" которая всегда будет делать вышеприведенный цикл и возвращать значение счетчика "SELL"?

Например:

 int Количество_ордеров()
  {
    SELL=0;
    int k=OrdersHistoryTotal()-1;
    for(; k>=0; k--)
    {
      if(!OrderSelect(k, SELECT_BY_POS, MODE_HISTORY)) continue;
      if(OrderType()==OP_SELL)SELL++;
    }
   return(SELL);
  }


Зачем здесь класс?

 
Dmitry Fedoseev:

Например, в одного эксперта надо впихнуть 100 вариантов трейлингстопа. При процедурном программировании получается вот такая портянка: 

100 идентичных участков кода. При работе программы обычно будет включен только какой-то один из трейлингов, остальные 99 ифов будут просто поедать ресурсы. 

Теперь вариант с OOP. При инициализации эксперта масштабируем массив с указателями, в соответствии с количество реально включенных трейлингов, создаем объекты только для включенных трейлингов. В итого постоянно работать будет примерно такой код:

Если включен один трейлинг, то cnt=1, то есть нет ничего лишнего.

Составьте массив имен функций, по индексу выбираете имя и обращаетесь. 


ООП тут не при чем. Это ограничение языка, которое пытаются решить с помощью ООП

 

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

 
Реter Konow:

Не понимаю, почему не сделать функцию "int Количество_ордеров()" которая всегда будет делать вышеприведенный цикл и возвращать значение счетчика "SELL"?

Доработав класс, получу x.SELL  x.BUY  x.ALL  и все, что нужно еще. И обращение к ним будет очень простое. Классы ООП - для простоты
 
Dmitry Fedoseev:

Конкретная задача. Заказчик заказ эксперта по двум МА, что бы в него были вставлены все имеющиеся в кодабазе варианты трейлинга, но и что бы в тестере не тормозило.

Да и еще с перспективой по доработке новыми вариантами трейлинга в будущем (не дорого).

Ясно. Это бесспорный аргумент в пользу ООП. Тупость заказчика и отсутствие времени с ней бороться и нежелание улучшать чужой алгоритм.)) Да, в этом случае ООП нужен. Согласен.)
 
STARIJ:
Доработав класс, получу x.SELL  x.BUY  x.ALL  и все, что нужно еще. И обращение к ним будет очень простое. Классы ООП - для простоты
Доработав функцию Вы можете получать все эти же переменные в массив, который в эту функцию будете передавать. Далее использовать по назначению...
 
СанСаныч Фоменко:

Составьте массив имен функций, по индексу выбираете имя и обращаетесь. 


ООП тут не при чем. Это ограничение языка, которое пытаются решить с помощью ООП

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

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

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