Интересное мнение про ООП - страница 10

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

Мне эта конструкция совершенно не нравится в плане читаемости и нагромождённости 

Согласен)))

Единственное оправдание такого - отладка)

 
Vitaly Muzichenko:

Мне эта конструкция совершенно не нравится в плане читаемости и нагромождённости 

изначально это мой вопрос был

последние примеры это утверждение @fxsaber , что при выполнении будут 100% разные коды, я дизасемблер из отладчика  выкладывал пару страниц назад - коды на 90% одинаковые

речи не идет об отказе возврата через return простых конструкций, которые читаются без проблем

 
Igor Makanu:

где то писали и тут разработчики похожую информацию

нашел только это:

switch это безопасный goto, в котором используется таблица переходов. Т.е. адрес 'case' вычисляется по целочисленному  ключу в switch. Из-за этого switch крайне эффективен даже по сравнению с if-else не говоря уже о более навороченных коллекций вроде словарей.

 
fxsaber:

Не получается ли здесь негативный эффект, когда пишется любого качества код из расчета "компилятор причешет до оптимального"?

При одном стиле написания знаешь точно, компилятор сделает, как надо. При другом - только уповать, что компилятор умнее.

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

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

 
Vasiliy Sokolov:

switch это безопасный goto, в котором используется таблица переходов. Т.е. адрес 'case' вычисляется по целочисленному  ключу в switch. Из-за этого switch крайне эффективен даже по сравнению с if-else не говоря уже о более навороченных коллекций вроде словарей.

круто! это полезная информация

спс!

 

Многие рекомендуют писать небольшие классы. Тот же Эккель говорит: "создавайте классы для единственной четко выраженной цели".

Сейчас работаю над советником, немного упрощенно напишу для примера. Есть там один из параметров "Достижение макс. количества стоплоссов". При получении SL должен работать в виде обратного счетчика до нуля и останавливать работу советника, а при получении ТП сброс в начальное значение, с отображением значения на панели.

Сделал отдельный класс для такого счетчика. Получилось, что он изменяется из нескольких точек, из OnInit при установке входных параметров, с панели из поля ввода, после закрытия ордера (sl и tp по разному меняют значение). Также главная функция вызывается из OnTick(), чтобы следить за достижением макс.количества стоплоссов для остановки советника.

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

Хотелось бы понимать, а как наилучшим образом организовывать взаимодействие объектов друг с другом, чтобы было меньше запутанности?  Есть ли какие-то хорошие статьи или книги с примерами кодов, диаграмм на эту тему и хорошим объяснением? Поделитесь, пожалуйста, кому что помогло научится писать хорошо спроектированные архитектуры.

 
Это не проблема ООП, а проблема общего подхода к созданию экспертов. Надо по истории считать количество стоплоссов. Вообще это то самое, для чего человеку дана голова, универсального решения нет.
 
Vitaly Muzichenko:

Мне эта конструкция совершенно не нравится в плане читаемости и нагромождённости 

На вкус и цвет.... все фломастеры разные.

Это было противопоставление "маленькому монстру":

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

Интересное мнение про ООП

fxsaber, 2021.01.31 01:09

Маленький монстр.

  static bool VirtualOrderSelect( const TICKET_TYPE Index, const int Select, const int Pool = MODE_TRADES )
  {
    return(VIRTUAL::SelectOrders ? VIRTUAL::SelectOrders.OrderSelect(Index, Select, Pool) :
           #ifdef VIRTUAL_SNAPSHOT_REFRESHTIME
             VIRTUAL::SnapshotPtr ?
             #ifdef __MQL5__ // Выбор по тикету в MT5 - разнообразный набор вариантов.
               (Select == SELECT_BY_TICKET) ? ::OrderSelect(Index, Select, Pool) && VIRTUAL::SnapshotPtr.CopyOrder()
                                            :
             #endif // #ifdef __MQL5__
                                              ((((Index == INT_MIN) || (Index == INT_MAX)) && (Pool == MODE_TRADES) &&
                                               ::OrderSelect(Index, Select, Pool) &&
                                             #ifdef VIRTUAL_SNAPSHOT_WITHOUT_HISTORY
                                               VIRTUAL::SnapshotPtr.CopyOrder(true))
                                             #else // #ifdef VIRTUAL_SNAPSHOT_WITHOUT_HISTORY
                                               VIRTUAL::SnapshotPtr.CopyOrder())
                                             #endif // #ifdef VIRTUAL_SNAPSHOT_WITHOUT_HISTORY #else
                                               || VIRTUAL::SnapshotPtr.OrderSelect(Index, Select, Pool))
                                  :
           #endif // #ifdef VIRTUAL_SNAPSHOT_REFRESHTIME
           #ifdef __MQL5__
             #ifdef __MT4ORDERS__
               ::OrderSelect(Index, Select, Pool)
             #else // __MT4ORDERS__
               false
             #endif // __MT4ORDERS__
           #else // __MQL5__
             ::OrderSelect(Index, Select, Pool)
           #endif // __MQL5__
           );
  }

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


 
Andrey Khatimlianskii:

На вкус и цвет.... все фломастеры разные.

Неправда. Они только на цвет разные, а на вкус все одинаковые…))))

 
Vitaly Muzichenko:

Мне эта конструкция совершенно не нравится в плане читаемости и нагромождённости 

С чего это ? 

Как раз наоборот, с двумя "ифами" - куда проще, чем с оператором "или". 

Явно проще проследить сперва одно условие, и уйти из функции, в случае выполнения, а потом проверить другое условие, и тоже уйти, в случае выполнения.  Чем прикидывать, что получается в результате сложного условия через логическое "или" (которое запросто можно спутать и "и"), и следить за обоими вариантами возврата. 

Довольно смешно читать ниже, что "оправдание такому - отладка", ведь это и значит, что такой код куда более понятен (иначе зачем он в отладке ?).

"Апофеозом" считаю одно выражение fxsaber'a, про которое он сам не смог сказать, как оно работает, заявив просто, что "код многократно оттестирован, и работает". Такого, на мой взгляд, быть не должно:

ENUM_ORDER_TYPE_FILLING CSymbolInfo::GetTypeFilling(string strSymbol,ENUM_ORDER_TYPE_FILLING otfFilingType)
{
   const ENUM_SYMBOL_TRADE_EXECUTION steExeMode = (ENUM_SYMBOL_TRADE_EXECUTION)::SymbolInfoInteger(strSymbol, SYMBOL_TRADE_EXEMODE);
   const int iFillingMode = (int)::SymbolInfoInteger(strSymbol, SYMBOL_FILLING_MODE);

   return((iFillingMode == 0 || (otfFilingType >= ORDER_FILLING_RETURN) || ((iFillingMode & (otfFilingType + 1)) != otfFilingType + 1)) ?
         (((steExeMode == SYMBOL_TRADE_EXECUTION_EXCHANGE) || (steExeMode == SYMBOL_TRADE_EXECUTION_INSTANT)) ?
           ORDER_FILLING_RETURN : ((iFillingMode == SYMBOL_FILLING_IOC) ? ORDER_FILLING_IOC : ORDER_FILLING_FOK)) :
          otfFilingType);
};

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


Я совершенно не могу понять, как он работает. И только полагаюсь на авторитет fxsaber'a.

Может быть, кто-нибудь объяснит ? 
 

1...345678910111213
Новый комментарий
Причина обращения: