Invalid request - только начал, и понять не могу... - страница 6

 
-Alexey-:

Почему, себе я написал, но для четверки.

То есть, лично Вами была написана универсальная библиотека, отвязанная от бизнес логики эксперта и которая может использоваться в любом эксперте?

В это тоже не верю. Конечно код обработчика ответов сервера был, но весь внутри бизнес-логики, а не в виде универсальной библиотеки.

 
Renat:

То есть, лично Вами была написана универсальная библиотека, отвязанная от бизнес логики эксперта и которая может использоваться в любом эксперте?

В это тоже не верю. Конечно код обработчика ответов сервера был, но весь внутри бизнес-логики, а не в виде универсальной библиотеки.

Да, могу доказать. За н-ную сумму, разумеется.
 
-Alexey-:
Да, могу доказать. За н-ную сумму, разумеется.

То есть, библиотеки и для МТ4 нет.

Не так уж и трудно было это доказать.

 
Renat:

То есть, библиотеки и для МТ4 нет.

Не так уж и трудно было это доказать.

Т.е. она есть. После перечисления денежных средств будет вам предоставлена хоть сейчас. А вот у вас ее нет ни для 4-ки ни для 5-ки.
 
Renat:

Ренат, у меня такое чувство, что использование стандартной библиотеки попадает под холивар: "ООП или не ООП"

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

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

 
-Alexey-:
Т.е. она есть.

нет её у вас.  все ошибки обрабатываются бизнес логикой.
Вы используете в МТ4 свойство синхронности, что упрощает в некоторой мере обработку, но ваши методы не гарантируют 100% всех случаев. Возможно 95% и то сугубо вашей библы, на которой и строится весь процесс торговли.
Но МТ5 в разы сложнее по обработке кодов возвратов + асинхронность.

Вы просите невозможного от обвертки. Стандартная библиотека - это не бизнес логика. Это обвертка "над" функциями терминал. Обвертка над начинкой конфеты.
Это удобный интерфейс, который берет на себя некоторую рутину. Забирая однотипный код на себя. Вы же не кушаете бумажную обвертку и не возмущаетесь почему она не съедобная. :)

Но гарантировать обвертка ничего не может, так как это вы выступаете гарантом. Ваша бизнес логика. начинка. :)
Как и функция Print не может гарантировать свободное место на диске.  И ошибок записи в лог. Для этого надо использовать обработку ошибок другими функциями и они конкретны для случаев.


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

Если хотите, можно пройтись по каждому коду возврата и рассмотреть основные возможные ситуации.

 
papaklass:

 
Ответьте на вопросы:
    - зачем мне тащить за собой все эти 61 метода? Это рационально?

вопрос уходит в плоскость - надо ли ООП программирование. Я не могу однозначно на него ответить. 
В своей практике я использую ООП для высокоуровневых моделей. 
В базе своей конечно много просто в функциях.

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


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

вы ошибаетесь. Они вообще никаких задач не решают. они обкрутили РУТИНУ.  Неужели сложно понять.


Соотвественно и обработка ошибок должна быть для всех решаемых задач.

Её там не может быть. Так как никаких задач библа не решает. Она упрощает РУТИНУ.  Всё.  На большее она не способна и её усложнять не будут и не нужно.

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

Ну дык это уже не обвертка рутины. Это уже решение проблем при конкретной логике ВАШЕГО эксперта.
Нельзя предусмотреть обработку ошибок даже в какой то одной единственной функции - открытия или закрытия.  Всегда найдется 1001 случай. когда предусмотренные ошибки не подходят и надо делать по другому.

Если вы знаете универсальную функцию на все ситуации - покажите её. Так как я даже представить себе не могу как можно не зная логики конкретного эксперта - заранее предусмотреть все возможные обработки ошибок.
Даже если и сделать такую функцию - это же противоречит всем вашим верхним словам - что "опять блин нагромоздили".

А если применить Ваш метод записи кода через макросы с учетом направления (ORDER_TYPE_BUY / ORDER_TYPE_SELL), то классы получатся достаточно компактными.
Где все это?

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

Вот если бы Ренат научился бы прислушиваться к предложениям с форума и стремился бы вникнуть в смысл этих предложений, МТ5 уже на данном бы этапе развития была бы намного впереди сегодняшнего положения. 

Ренат постоянно повторяет - мы на техническом форуме.  Мы не можем тут говорить про абстрактные вещи.

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

 
papaklass:

Ответьте на вопросы:

    - если мне нужно просто выставить рыночный ордер, или отложенный ордер, то зачем мне тащить за собой все эти 61 метода? Это рационально? 

   - если у меня есть открытая позиция и мне нужно установить просто стопы, зачем мне тащить весь этот функционал с 61-ми методами? Это рационально?

   - если у меня есть открытая позиция со стопами, которые сработают при достижении цены их уровня, зачем мне тащить все эти 61 метод? Это рационально?

Вам никто не запрещает:

  1. Не пользоваться готовыми решениями в виде уже написанных кем-то библиотек, а писать свой код с нуля.
  2. Переписать уже готовую библиотеку в виде модифицированных классов, удалив из нее методы, которые по Вашему мнению являются "лишними".
  3. Переопределить методы из готовой библиотеки, путем наследования
 
papaklass:

 

Что к чему, "разделить операции для торговых операций по разным классам."

Это тоже самое как если бы у вас были разные эксперты для открытия, закрытия и модификации. Вроде и можно, но никто так не делает(за редким исключением, спец задачи).

И мне очень нравится, фраза "если мне нужно просто выставить рыночный ордер, или отложенный ордер, то зачем мне тащить за собой все эти 61 метода? Это рационально?"

Ну на один эксперт будет накладных расходов где-то 100кб памяти. Ужооооос... 


Вот кстати опрос Используете ли вы стандартную библиотеку для торговых операций?

 
papaklass:

Чесно говоря, зря я вылез со своим постом.

Не зря, я понял, что не один такой нестандартный :)   В опросе - проставился
Причина обращения: