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

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

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

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

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

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

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

• для каждого типа ФИ определить подкласс

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

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

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

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

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

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

С уважением,

Томас

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

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), не беспокоясь о том, какой это тип.

чт.