Как смоделировать цену (чистую или грязную) финансового инструмента?

Question

Мне нужна помощь в моделировании следующей ситуации:

У финансового инструмента всегда есть цена. Тем не менее, некоторые финансовые инструменты (точнее, определенных типов) также имеют так называемую "чистую" цену, которая является атрибутом, который зависит (помимо прочего) от цены, и в этом случае цена также называется "грязной" ценой. Существует услуга калькулятора, которая вычисляет как цену (или грязную цену), так и чистую цену. Как лучше всего концептуально моделировать эту ситуацию?

Я рассмотрел две альтернативы:

1. ФинансовыйИнструмент имеет цену

   FinancialInstrument
     + price: Price
   

   где Price - это супертип с двумя производными классами: DirtyPrice и CleanPrice. CleanPrice зависит от DirtyPrice

   CleanPrice
     + dirty: DirtyPrice
   

   Служба калькулятора рассчитывает стоимость финансового инструмента:

   CalculatorService
     + compute_price(FinancialInstrument, ...): Price
   

2. FinancialInstrument - это супертип с двумя производными: PlainFinancialInstrument (имеет только атрибут цены) и CleanPriceFinancialInstrument, который имеет чистые и грязные цены.

                          FinancialInstrument
                            + price: double
   
   PlainFinancialInstrument                   CleanPriceFinancialInstrument
                                                + clean_price: double
   

   Служба калькулятора будет тогда иметь два метода для вычисления цены для PlainSecurity или чистой и грязной цены для CleanPriceSecurities:

   CalculatorService
      + compute_price(PlainFinancialInstrument, ...): double
      + compute_price(CleanPriceFinancialInstrument, ...): pair<double, double>
   

Каковы компромиссы обеих альтернатив? Есть ли другие альтернативы?

Благодарю.

Answer 1

Мне не ясно, спрашиваете ли вы, как смоделировать абстрактную проблему, которая указана с помощью вашего примера, или вы пытаетесь смоделировать бизнес-концепцию ценообразования финансовых инструментов в контексте реального мира. Я думаю, что это последнее, потому что вы достаточно конкретны, поэтому я прокомментирую это. В этом случае я сомневаюсь, однако, что любой из ваших двух подходов достаточно сложен, чтобы удовлетворить потребности вашей задачи. Я работал в течение нескольких лет в этой области.

Я не уверен, в какой сфере бизнеса вы работаете. В сфере, в которой я работал (банковское дело), ​​разница между чистой и грязной ценой - простая бизнес-концепция. Например, для облигаций, оцененных по амортизированной стоимости, чистая цена - это стоимость дисконтированного денежного потока без учета начислений и отсрочек, грязная цена - это сумма чистой цены и начислений / отсрочек. Во всех известных мне случаях чистая цена - это разница между грязной ценой и в большинстве случаев простыми функциями некоторых показателей финансового инструмента (FI для краткости), а чистая и грязная цена являются только показателями, которые имеют отношение для некоторых (но не для всех) видов финансовых инструментов.

С другой стороны, в зависимости от ОПБУ и сферы деятельности вопрос о том, нужно ли вам указывать чистую или грязную цену или и то, и другое, может зависеть от того, какой книге назначен финансовый инструмент, например, банковской книге / торговой книге. Для торговой книги, которую вы обычно хотите получить только за грязную цену, чистая цена актуальна в банковской книге.

Что еще хуже, FI может быть, например, переназначен, что приведет к тому, что другой набор ключей станет актуальным. Вы должны убедиться, что ваш дизайн учитывает последствия таких изменений, если это уместно в вашем контексте.

Лично я бы начал с подхода, изложенного ниже:

• создать абстрактный класс / интерфейс для финансового инструмента

• для каждого типа FI определите подкласс

• создайте список всех показателей, которые могут стать релевантными для любого возможного FI, имеющегося в вашей области действия - в вашем примере: чистая цена и грязная цена, и, возможно, один для показателя, представляющего разницу. Дополнительно создайте фиктивную запись показателя цены.

• для каждого из этих показателей создайте интерфейс показателей с методами, релевантными для KF. Например, рассчитать, обновить - это зависит от вашей общей модели. Опять же для вашего примера: чистый интерфейс цены, грязный интерфейс цены, интерфейс дельты и интерфейс цены. Может возникнуть необходимость определить порядок, в котором они должны обновляться. Набор методов интерфейса цены должен быть подмножеством чистого и грязного интерфейса цены.

• для каждого типа FI создайте конкретную реализацию (класс) для всех интерфейсов показателей, относящихся к этому типу FI, с учетом, конечно, повторного использования. Строго избегайте использования операторов if/else или switch в зависимости от показателя или типов FI в этих реализациях. Если это окажется необходимым, вам понадобятся дополнительные определения классов. Теперь, когда вы создаете экземпляр класса, представляющего FI, используйте шаблон фабрики для создания экземпляров интерфейсов показателей. Таким образом, вы выбираете экземпляр экземпляра FI, какой метод использовать для расчета, а затем экземпляр FI знает, как рассчитать показатели FI. Приятной особенностью фабричного шаблона является то, что вы можете дополнительно учитывать книгу, для которой вы рассчитываете, а также другие параметры, даже во время выполнения, если это необходимо. Фабрика позволит интерфейсу показателя цены просто указывать на экземпляр, который имеет отношение к контексту.

• то, что вы называете службой калькулятора, будет затем, для расчета цены, вызывать метод интерфейса с ключом цены, но экземпляр, на который указывает интерфейс, предоставляется экземпляром FI, потому что фабрика просто сопоставила интерфейс цены с чистым интерфейс цены или грязный интерфейс цены в зависимости от того, что является правильным для данного конкретного FI в данном конкретном контексте.

Если вы используете, как предложено, список соответствующих показателей и реализаций интерфейса расчета показателей в экземпляре FI, вы даже можете обновить / обменять его во время выполнения, если FI переназначен, без необходимости удалять / воссоздавать экземпляр FI.

Надеюсь, я не сделал ваш вопрос более сложным, чем на самом деле.

С Уважением,

Томас

Answer 2

Вам нужен отдельный калькулятор? Если нет, то как насчет:

class FinancialInstrument {
    private price: Double;

    public getPrice {
       // calculate the price
       // presumably sets the private price?  Dunno
       this.price= // etc. .....
       return this.price;
    } 

class CleanFinancialInstrument extends FinancialInstrument {
    private cleanPrice: Double;

    public getPrice {
       //override FinancialInstrument.getPrice() as required
    }

    public getDirtyPrice {
       //do you need this? Dunno
       return this.getPrice();
    }

    public getCleanPrice {
       this.cleanPrice = //... etc.
       return this.dirtyPrice;
    }
}

Возможно, вам даже не понадобятся локальные частные переменные, если вы не кэшируете цену.

Вызывающие могут просто вызывать getPrice() для любого экземпляра (FinancialInstrument или CleanFinancialInstrument), не беспокоясь о том, какой это тип.

НТН.