Расчет Цены опциона если...

longtrades: Если я сделаю такое : не изменит ли это LastTrade.Price самого инструмента БА ? LastTrade.Price на каждом тике меняется, поэтому, наверное, толку от этого не будет.

Может быть так:

namespace StockSharp.Algo.Derivatives
{
    using System;

    using Ecng.Common;
    
    using StockSharp.BusinessEntities;

    public class MyBlackScholes : BlackScholes
    {
    	public MyBlackScholes(Security option) : base(option)
    	{
            SecurityPriceMode = SecurityMiscPrice;
    	}

    	private static decimal UnderlyingPrice { get; set; }
    	
    	public static readonly Func<Security, decimal> SecurityMiscPrice = s => UnderlyingPrice;
    	
        new public decimal Premium(decimal price)
        {
      	    UnderlyingPrice = price;
            return base.Premium();
        }
    }
}

    var premium = (new MyBlackScholes(Security)).Premium(141000);

Коллеги, надо наверное сделать статически формулы. Я сам в свое время не допёр до этого, повелся на ООП. К сожалению, ООП и алготрейдиинг идут не в ногу (громко сказано, но реально это так). Уже и сам не раз натыкался на, скажем, ограниченность существующих классов. Подумаю, как лучше сделать.

Михаил Сухов: Коллеги, надо наверное сделать статически формулы. Я сам в свое время не допёр до этого, повелся на ООП. К сожалению, ООП и алготрейдиинг идут не в ногу (громко сказано, но реально это так). Уже и сам не раз натыкался на, скажем, ограниченность существующих классов. Подумаю, как лучше сделать. ООП многогранен, особенно в C#, где он переплетается с событиями, функциональщиной и декларативностью. (Кстати в StockSharp.Xaml вы смачно WPF изнасиловали. Но это не совсем ваша вина. Там всё очень жёстко. Без поллитры не разберёшься. ) Я продолжаю настаивать, что для алго ООП - это самое то, что доктор прописал.

Места, где ООП не рулит:

• принципиально функциональная логика
• хранение данных
• аспекты
• распределённые транзакции
• межпроцессное/межсерверное взаимодействие Последние два случая немного (но не до конца) лечит WCF. Косяки с непролезанием интерфейсов через коллекции уже замечательно вылечили. Дженерики тоже очень хороши (Говорят, они были в движке изначально. Поэтому так всё и ускоряют.)

Ограниченность классов - это не проблема ООП, а проблема реализации.

Обращаю внимание на BLToolkit. Там довольно эффективно решаются вторая и третья проблемы, а также ещё лучше реализуется клонирование, мапинг объектов, работа с коллекциями и устраняются тормоза Reflection.

Статика вредна, потому что она к хренам ломает все принципы ООП (препятствует наследованию и т.п.) Кстати о наследовании: было бы замечательно, если бы бОльшая часть private полей в той же Strategy и других основных классах была protected (хотя бы те, которые подразумевают какие-то сущности). Это бы на порядок облегчило жизнь. Если боитесь излишнего их использования, сделайте класс-наследник-фасад (точнее, можно перенести основной функционал в какой-нибудь Base, а старый класс сделать фасадом, как было в старом добром Delphi) Правда в C# с этим не заморачиваются, а просто используют в качестве ограниченных фасадов интерфейсы (к слову о статике, которая этого не позволяет).