Привет всем! В предыдущих статьях я описывал свой тестер, разработанный на 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);
}

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

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

– Привет! В предыдущий раз, ты рассказывал про дата-сервис, про отдельный слой доступа к данным. Расскажи теперь про сами сущности и репозитории. При помощь чего ты вытягиваешь данные из таблиц?

– Ок. Если необходимо сохранять сделки и статистику, или откуда-то брать исторические котировки для тестов, то неплохо использовать БД. Но, как с ней общаться? Есть несколько способов. В C#, есть например традиционный ADO.NET, но речь пойдёт не о нём. В прошлый раз мы отделили работу с БД от бизнес-логики, это уже очень здорово, но можно пойти дальше! Есть способ общаться с самой БД на достаточно абстрактном уровне, инкапсулируя детали формирования самих запросов. Такой способ лучше вписывается в концепцию объектно-ориентированного проектирования, и называется он ORM (object relation mapping).

– Хм, я что-то слышал про ORM. У меня сложилось неоднозначное ощущение, вроде, есть целое сообщество, кто против них (OrmHate), и считает это антипаттерном. Все эти дополнительные уровни абстракции, и вообще, они наверно дико тормозные?