Михаил Сухов Коллеги, надо наверное сделать статически формулы. Я сам в свое время не допёр до этого, повелся на ООП. К сожалению, ООП и алготрейдиинг идут не в ногу (громко сказано, но реально это так). Уже и сам не раз натыкался на, скажем, ограниченность существующих классов. Подумаю, как лучше сделать.
ООП многогранен, особенно в C#, где он переплетается с событиями, функциональщиной и декларативностью.
(Кстати в StockSharp.Xaml вы смачно WPF изнасиловали. Но это не совсем ваша вина. Там всё очень жёстко. Без поллитры не разберёшься. )
Я продолжаю настаивать, что для алго ООП - это самое то, что доктор прописал.
Места, где ООП не рулит:
- принципиально функциональная логика
- хранение данных
- аспекты
- распределённые транзакции
- межпроцессное/межсерверное взаимодействие
Последние два случая немного (но не до конца) лечит WCF.
Косяки с непролезанием интерфейсов через коллекции уже замечательно вылечили.
Дженерики тоже очень хороши (Говорят, они были в движке изначально. Поэтому так всё и ускоряют.)
Ограниченность классов - это не проблема ООП, а проблема реализации.
Обращаю внимание на
BLToolkit. Там довольно эффективно решаются вторая и третья проблемы, а также ещё лучше реализуется клонирование, мапинг объектов, работа с коллекциями и устраняются тормоза Reflection.
Статика вредна, потому что она к хренам ломает все принципы ООП (препятствует наследованию и т.п.)
Кстати о наследовании: было бы замечательно, если бы бОльшая часть private полей в той же Strategy и других основных классах была protected (хотя бы те, которые подразумевают какие-то сущности). Это бы на порядок облегчило жизнь.
Если боитесь излишнего их использования, сделайте класс-наследник-фасад (точнее, можно перенести основной функционал в какой-нибудь Base, а старый класс сделать фасадом, как было в старом добром Delphi)
Правда в C# с этим не заморачиваются, а просто используют в качестве ограниченных фасадов интерфейсы (к слову о статике, которая этого не позволяет).