ООП, чтоб он был здоров.... - страница 2

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

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

 
Alexey Volchanskiy:

Золотые слова! Добавлю, сильно уменьшается время последующих разработок. Например, у меня в личной библиотеке есть класс COrderManager, который умеет работать с пулом ордеров, строить сетки отложенников, двигать сетки вверх-вниз по цене, растягивать и сжимать их и т.д. Если представить, что я все это делал бы на процедурном... бр-р-р-р))

ЗЫ: как вспомню "старый" MQL4, в котором даже структур не было, так вздрогну ))

Ну насколько я понял Ваш класс  COrderManager и есть ни что иное как "контейнер функций"...... Ведь пока он у Вас "лежит" в библиотеке - он просто код. А как понадобится - набор функций (в ООП - методов)....
 
Эраст, а в каком конкретно месте ООП вы застряли? Как контейнеры для функций используете... а в каком месте не покатило?
 
Эраст Ковалев:
Ну насколько я понял Ваш класс  COrderManager и есть ни что иное как "контейнер функций"...... Ведь пока он у Вас "лежит" в библиотеке - он просто код. А как понадобится - набор функций (в ООП - методов)....

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

class COrderManager : CObject
{
private:
    CList*  m_listMarketOrders;
    CList*  m_listPendingOrders;
    CList*  m_listHistOrders;
    color   m_colorBuy, m_colorSell;
    int     m_hLogOrders;
    int     m_hLogAllOrders;
    bool    m_enableStrategyLogFile;
    bool    m_enableAllLogFile;
    int     m_arrowIdx;
    double  m_priceStep; // as 0.0001 for example for EURUSD
    bool    m_orderModifyAfterOpen;

    COrder* FindOrderInList(CList* list, int ticket, int& idx);
    //int Add();
    CList*  GetListByTypeOfOrder(TypeOfOrder ordType)
    {
        CList* list = NULL;
        switch (ordType)
        {
        case toHistory:
            list = m_listHistOrders;
            break;
        case toPending:
            list = m_listPendingOrders;
            break;
        case toMarket:
            list = m_listMarketOrders;
            break;
        default:
            Alert("COrderManager::GetListByTypeOfOrder - тип ордера не существует!!!");
            break;
        }
        return list;
    }
 
Alexey Volchanskiy:

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

Здесь проблема в том, что создается вторая сущность: некая копия реальных ордеров в МТ и не факт, что она будет совпадать с фактической ситуацией. Например ордер отмениться, а в копии он будет продолжать существовать.

Может быть COrderManager и быстрее, но вот обычный перебор OrderSelect гораздо надежнее. 

 

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

 
Vasiliy Sokolov:

Может быть COrderManager и быстрее

Не может, бо работа с объектами по определению требует больше ресурсов

 

George Merts:

с применением ООП существенно повышается удобство повторного использования кода

Что мешает повторно использовать набор функций? Объём неиспользуемого кода и отжираемые ресурсы сократятся в разы

---

На моё имхо ООП оправдан только там, где есть масштабирование структур, т.е. где наследование свойств/методов действительно востребовано и работает. Это меньше 1% работ во фриланс-сервисе

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

 
Alexander Puzanov:

Что мешает повторно использовать набор функций? Объём неиспользуемого кода и отжираемые ресурсы сократятся в разы

Я говорил про удобство повторного использования. При ООП между методами и данными - организована связь, которая (при правильном проектировании класса) сразу предотвращает большое количество ошибок.

Ресурсы - да, согласен, при ООП их нужно больше.

Alexander Puzanov:

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

Вот-вот. И мне тоже это весьма нравится.
 
Alexander Puzanov:

Что мешает повторно использовать набор функций? Объём неиспользуемого кода и отжираемые ресурсы сократятся в разы

...

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

Включая класс дерективой #include мы точно знаем, что все связи учтены и содержимое инклудника закомпилится без ошибок. 

 
Vasiliy Sokolov:

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

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

 

George Merts:

Я говорил про удобство повторного использования

Я согласен на 100% - это удобно. Но у этого удобства есть цена - классы содержат избыточный код и избыточный функционал, если каждый раз подгонять его строго под конкретные нужды конкретной программы всё удобство потеряется. А с отдельными функциями проще подобрать только то, что необходимо. Поскольку mql-программы не оч требовательны и к объёму кода и к ресурсоёмкости на 'даунгрейдинг' классов к нуждам конкретной программы можно забить. Но я бы не отнёс удобство использования за счёт избыточности кода к преимуществам ООП
123
Новый комментарий
Причина обращения: