Торговый робот

     Привет всем! В предыдущих статьях я описывал свой тестер, разработанный на C#, и, несколько раз подчёркивал, что переключение между двумя режимами (тестирование/торговля) может быть простым. Код стратегий не должен зависеть от того, кто поставщик маркет-даты и куда уходят заявки – в тестовую базу или на сервер брокера. Конечно, это лишь один из подходов, и кому-то он покажется странным, но, главное его достоинство заключается в том, что тестирование приближается к реальности, что даёт более достоверные результаты. Вопрос в следующем: как, имея один и тот же код, получать разные по функциональности программы? Один из вариантов – использовать инверсию управления и внедрение зависимостей! Об этом сегодня и пойдёт речь.

    Приведу пример нехорошего (иногда, говорят – с запашком) кода:

class Strategy
{
   public Strategy()
   {
     var mgr = new TestOrderManadger();
     mgr.PlaceOrder(...);
   }
}

     Здесь плохо то, что класс Strategy зависит от класса TestOrderManadger. В такой реализации нельзя начать использовать какой-нибудь другой менеджер заявок (AnotherOrderManadger) без перекомпиляции библиотеки с классом Strategy. Тем более тут нарушается принцип единства ответственности – класс Strategy, помимо своей прямой обязанности, также, создаёт внутри себя зависимости. Чтобы исправить ситуацию, можно использовать интерфейсы:

interface IOrderMandger
{
   void PlaceOrder();
}

class TestOrderManadger : IOrderMandger
{
   public void PlaceOrder(){}
}

class Strategy
{
   public Strategy(IOrderMandger orderMandger)
   {
     var mgr = orderMandger;
     mgr.PlaceOrder(...);
   }
}

     Привет всем! В предыдущем посте рассматривались два объекта, которые формируют закрытые позиции и считают статистику торговли (IClosePositionManager, IResultManager). Сегодняшняя статья будет посвящена визуализации этих данных и общей архитектуре торговой системы.

     В своё время я рассказывал про паттерн проектирования MVC, что логика должна быть отделена от визуализации, и ещё, что у каждой формы должен быть свой презентер. Также хотел отметить, что проект лучше разбивать на несколько логических модулей (библиотек классов в c#). Свой проект я разделил на: definitions – содержит базовые, ни от кого не зависящие классы, интерфейсы и описания, local – реализация интерфейсов для локального тестера, smartcom – реализация интерфейсов для коннектора, в данном случае смарткома, strategies – вынес в отдельный модуль все стратегии, UI – внешний интерфейс системы (формы и их презентеры) и т.д. В каждом таком модуле я обычно создаю ещё несколько папок – в модулеUI, например, есть папка interfaces, presenters и views.

     Добрый день. В предыдущих частях я описывал, как на C# сделал собственный тестер, применяя объектно-ориентированный подход, рассказывал про интерфейсы, про их реализации, и, рассказывал про работу с БД. На данный момент осталось совсем немного. В этом топике я опишу вариант расчёта результатов работы стратегии.

     Чтобы не запутаться, даже не читая предыдущие топики, поясню, что есть и к чему надо придти. Есть стратегии – это некий объект программы, который выставляет заявки на основе получаемой маркет-даты. Заявки (Order) регистрируются системой. Также, регистрируются сделки прошедшие по заявке (каждая заявка имеет список сделок — List<Trades> trades). После прогона стратегии, все заявки и сделки сохраняются в БД, и после, их можно извлечь и посчитать по ним статистику работы стратегии. По сути, эта статистика состоит из двух аспектов: сами закрытые позиции и оценка эффективности на их основе. Начнём с первого. Вот интерфейс, который принимает заявки со сделками, и, выдаёт, собственно, список закрытых позиций:

interface IClosePositionManager
{
   List<ClosePosition> ClosePositions (List<Order> orders);
}

     Да! Именно так! Разработка собственного тестера или покупка готового не приведёт к успеху, если нет самого главного – идеи. Можно прятаться за кучей графиков или оправдывать себя горой ненужного “профессионально написанного кода”, коллекционировать и применять кстати и не кстати различные термины, знать на зубок тервер и математику. Но нет идеи – нет и денег!

     Откуда появляются идеи? Может, это совокупность опыта, природной чувствительности, удачи? Так, или иначе, необходимо отбросить на самом раннем этапе всё несущественное, и выявить или почувствовать перспективные направления, чтобы не тратить время на просто перебор. Энтузиазм, как один из важнейших факторов успеха, может быть сведён на нет постоянными неудачами переборов. Тестер – это помощник, позволяющий отшлифовать алгоритм, а не создать его. Но, к слову сказать, найти хорошую идею можно и с помощью него – перебор тоже, совершенно случайно, может дать результат, но он, всё-таки, никогда не будет давать стабильные результаты. Грааль спрятан внутри!

Анализ графика проведен с помощью аналитической программы по автоматическому анализу биржевых графиков PATTERN ANALYZER.

Программа Pattern Analyzer обнаружила на графике Газпром ао, H1 новый торговый сигнал (графический паттерн):

Название фигуры: Двойная вершина
Тип сделки: продажа
Стоп-лосс выше: 124,30
Тейк-профит: 117,70

Трейдер из нашей тусовки покончил с жизнью и задушил дочку. Мнение и совет всем трейдерам. Источник lenta.ru/news/2017/09/30/igral/

00:00 Введение про проигравшегося трейдера, убившего свою дочь и покончившего свою жизнь сам
00:40 Как и когда у меня были мысли о суициде
03:00 Личный пример почему думать об суициде глупо
05:08 Торговля на бирже сама по себе не приводит к суициду
06:55 Всегда думайте о рисках, даже если не торгуете на бирже
07:40 Всегда задавайте себе вопрос «А ЧТО СЛУЧИТСЯ, ЕСЛИ… ?»
09:40 Что делать, если профукал денежки инвестора
11:55  БУДЬТЕ ПАРАНОИКОМ!