Хочу переделать OrderStates: слить два состояния Cancelled и Matched в
одно - Done. И добавить 3 extension метода: IsCancelled IsMatched
IsPartiallyFilled.
Зачем это - Canceled и Matched четко отражали реальное состояние
заявки в квике - Снята и Исполена, это можно было анализировать и
предпринимать различные действия. А Done это все испротит. А методы
добавить - отличная идея, но зачем же состояния убирать?
а если необходима разная реакция на снятие заявки и ее исполенние? во
тя сейчас делаю арбитражера, мне именно такая реакция нужна..
Состояние частичное реализации можно сделать 3 способами
а) еще один State в дополнение к Matched и Canceled - тот же
OrderStates.PartialyMatched
б) метод расширения или свойсво IsPartialyMatched
в) тупо провреить Volume-Balance == Volume.
Еще раз повторюсь - текущие OrderStates полностью отражают реаьное
состояние заявки в системе. А Done - слабая информативность, тока в
любом случае придется проверить - а че именно то Done - сняли или
исполнили?
А вопрос - почему имеено Вы решили слить два состояния в одно?
Причина - отделить бизнес состояния от системных. Заявка по сути живет
следующий цикл: еще не принята, принята и активна, принята и не
активна. Это системные статусы, диктуемые биржей. Бизнес статусы - это
ничего вообще не исполнили, исполнили хоть что-то и слаба богу, мне
повезло я все исполнил.
К примеру, если использовать текущий подход, то можно получить заявку,
которая PartiallyMatched и Canceled одновременно. С точки зрения
человеческой логики - это абсурд. С точки зрения биржи - заявка
частично исполнилась, но мы ее сняли.
Ок, давайте Ваш случай. Где будет новая концепция не удобна?
Арбитражер.
Например робот выставляет заявку. Она
а) выполняется целиком - я вижу что она матчед, кидаю правую часть
б) Vol-Bal != Vol - я кидаю правую часть на vol-bal, и снимаю левую
часть
в) висит в стакане - трейдер это видит, РУКАИТ снимает ее, я вижу что
она Canceled, вибрысываю ее из коллекции для обработки заявок
вот тут то мне и надо смотреть кто Matched, кто частично исполнене, а
кто Canceled. И повторюсь еще раз - состояния Matched/Canceled
отражают реальное состояие заявки в торговом шлюзе.И кстати Matched/
Canceled - это самые что нинаесть бизнес состояни, а системные - этот
свойство Status.
кстати Вашу модель " Бизнес статусы - это
ничего вообще не исполнили, исполнили хоть что-то и слаба богу, мне
повезло я все исполнил." надо доплнить статусом - непонятно что
произошло, но заявку сняли от греха подальше :).
в принципе,Мтхаил, можно же еще одно свойсво ввести - бизнес
состояние. зачем ломать старое, которое широко используется?
Спокойствие, еще пока ничего не сломано. Поэтому и консультируюсь.
Если бы сломал - уже не до консультации.
order.IsMatched() будет короче, чем order.State ==
OrderStates.Matched
А вот тут мне кажется логика хромает. Кидать надо то что осталось,
и не важно, полностью исполнилось или нет.
И опять неправильный на мой взгляд подход. Завтра Вы сделаете,
чтобы робот сам снимал заявки по определенному условию и уже не
различите, кто снимал, человек или робот. Надо коллекцию делать из тех
заявок, что снимаются программно и что ручками. Если заявка снята
челом, то она будет отсутствовать в той коллекции.
Как плюс. Вы снимаете заявку. Вы какого статуса дожидаетесь? Если
только Canceled то не правильно. Надо два. А так будет только одна
проверка.
Опять же, из выше приведенной логики следует, что не так важно,
снята заявка или исполнилоась или активна все еще, а сколько
реализована контрактов.
Matched/Canceled - бизнес состояния. Я так и писал.
Робот и так будет снимать заявки по определенному условию, а так же их
может снять человек.
и я не могу знать кто снял - робот или человек.получается менятее шило
мыло - придется писать
if(order.State == OrderStates.Done && otder.IsCancel)
делаем одно (выяснем сколько контрактов таки прошло и на это колво
бросаем правую)
评论 (10)
登录 或 创建账户, 登录或注册以发表评论
ай-ай, баба Яга против! это же нахрен летит ручная коррекция работы робота!
Зачем это - Canceled и Matched четко отражали реальное состояние заявки в квике - Снята и Исполена, это можно было анализировать и предпринимать различные действия. А Done это все испротит. А методы добавить - отличная идея, но зачем же состояния убирать?
Минусы текущего:
а если необходима разная реакция на снятие заявки и ее исполенние? во тя сейчас делаю арбитражера, мне именно такая реакция нужна.. Состояние частичное реализации можно сделать 3 способами
а) еще один State в дополнение к Matched и Canceled - тот же OrderStates.PartialyMatched б) метод расширения или свойсво IsPartialyMatched в) тупо провреить Volume-Balance == Volume.
Еще раз повторюсь - текущие OrderStates полностью отражают реаьное состояние заявки в системе. А Done - слабая информативность, тока в любом случае придется проверить - а че именно то Done - сняли или исполнили?
А вопрос - почему имеено Вы решили слить два состояния в одно?
Даже наверно не нужно пункт а) - а то придется в некторых случаях 3 статуса проверять :)
Причина - отделить бизнес состояния от системных. Заявка по сути живет следующий цикл: еще не принята, принята и активна, принята и не активна. Это системные статусы, диктуемые биржей. Бизнес статусы - это ничего вообще не исполнили, исполнили хоть что-то и слаба богу, мне повезло я все исполнил.
К примеру, если использовать текущий подход, то можно получить заявку, которая PartiallyMatched и Canceled одновременно. С точки зрения человеческой логики - это абсурд. С точки зрения биржи - заявка частично исполнилась, но мы ее сняли.
Ок, давайте Ваш случай. Где будет новая концепция не удобна?
Арбитражер. Например робот выставляет заявку. Она а) выполняется целиком - я вижу что она матчед, кидаю правую часть б) Vol-Bal != Vol - я кидаю правую часть на vol-bal, и снимаю левую часть в) висит в стакане - трейдер это видит, РУКАИТ снимает ее, я вижу что она Canceled, вибрысываю ее из коллекции для обработки заявок вот тут то мне и надо смотреть кто Matched, кто частично исполнене, а кто Canceled. И повторюсь еще раз - состояния Matched/Canceled отражают реальное состояие заявки в торговом шлюзе.И кстати Matched/ Canceled - это самые что нинаесть бизнес состояни, а системные - этот свойство Status. кстати Вашу модель " Бизнес статусы - это ничего вообще не исполнили, исполнили хоть что-то и слаба богу, мне повезло я все исполнил." надо доплнить статусом - непонятно что произошло, но заявку сняли от греха подальше :).
в принципе,Мтхаил, можно же еще одно свойсво ввести - бизнес состояние. зачем ломать старое, которое широко используется?
Спокойствие, еще пока ничего не сломано. Поэтому и консультируюсь. Если бы сломал - уже не до консультации.
Робот и так будет снимать заявки по определенному условию, а так же их может снять человек. и я не могу знать кто снял - робот или человек.получается менятее шило мыло - придется писать
if(order.State == OrderStates.Done && otder.IsCancel) делаем одно (выяснем сколько контрактов таки прошло и на это колво бросаем правую)
if( order.State == OrderStates.Done && otder.IsMatched)
делаем другое (бросаем правую чтобы перекрыто все контракты из левой)
if( order.State == OrderStates.Done && otder.IsPartialyMatched)
снова определяем сколько контрактов таки прошло?
а если часть заявки прошла, а потом ее сняли? какой статус будет?
Не надо так. order.IsCanceled() достаточно
order.IsMatched()
order.State == Done order.IsPartiallyMatched() = true