2011-11-20 228 views
0

我需要建模以下情況的幫助:如何建模金融工具的價格(乾淨或骯髒)?

金融工具總是有一個價格。然而,某些金融工具(某些類型的)也有所謂的「清潔」價格,這是一種依賴於(除其他外)價格的屬性,在這種情況下,價格也被稱爲「骯髒」價格。有一個計算器服務計算價格(或髒價格)和清潔價格。如何最好地從概念上模擬這種情況?

我已經考慮兩種選擇:

  1. FinancialInstrument有價

    FinancialInstrument 
        + price: Price 
    

    這裏是價格有兩個派生類的超類型:含息價格和除息價格。除息價格取決於含息價格

    CleanPrice 
        + dirty: DirtyPrice 
    

    然後計算器服務將計算FinancialInstrument價格:

    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> 
    

什麼都替代品的取捨?還有其他的選擇嗎?

謝謝。

+0

那是什麼有兩種價格的金融工具,並且只有一個金融工具之間的區別? –

回答

2

我不清楚你是在詢問如何模擬通過你的例子指定的抽象問題,或者你是否試圖在現實世界中對金融工具定價的商業概念建模。我認爲這是後者,因爲你很具體,所以我會對此發表評論。但是,在這種情況下,我懷疑你的兩種方法中的任何一種方法都足夠複雜以滿足你的任務需求。我在這方面工作了好幾年。

我不確定你在哪個業務領域工作。在我曾經工作過的地區(銀行業務),乾淨和骯髒的價格之間的差異是一個簡單的商業概念。例如,對於以攤餘成本評估的債券,清算價格是不考慮應計和遞延的貼現現金流量的價值,骯髒的價格是清算價格和應計/遞延的總和。在我所知道的所有情況中,清潔價格是髒價格和某些大多數時間之間的差異。金融工具的一些關鍵數據(簡稱FI)的簡單功能,乾淨和骯髒的價格都是關鍵數字,是相關的對於一些(但不是全部)金融工具。另一方面,根據GAAP和業務領域的情況,您是否需要提供清潔或骯髒的價格或兩者兼有的問題可能還取決於金融工具分配到哪本賬戶,例如銀行賬戶/交易書。對於交易賬戶,您通常只希望檢索骯髒的價格,而清潔價格與銀行賬戶相關。

爲了讓事情變得更糟,FI可以被重新分配,導致不同的密鑰配置集變得相關。如果您的設計與您的環境相關,則應確保您的設計將這些更改的後果考慮在內。

個人而言,我對概括爲一種方法啓動如下:

  • 創造金融工具

  • 一個抽象類/接口每種類型FI的,定義一個子類

  • 創建一個所有關鍵數字的列表,這些關鍵數字可能與您在範圍內的任何可能的FI有關 - 例如:清潔價格和骯髒的價格,可能還有一個代表差異的關鍵數字。另外創建一個虛擬價格關鍵數字條目。

  • 對於這些關鍵數字中的每一個,使用與KF相關的方法創建關鍵圖形界面。例如。計算,更新 - 這取決於你的整體模型。再舉一個例子:乾淨的價格界面,髒價格界面,增量界面和價格界面。可能有必要定義它們必須更新的順序。價格接口的一套方法必須是每種FI類型的清潔和髒價格接口的子集,爲所有與FI類型相關的關鍵圖形接口創建一個特定的實現(類)當然,重新考慮。根據這些實現中的關鍵數字或FI類型,嚴格避免if/else或switch語句,如果事實證明這是必要的,則需要額外的類定義。現在,當您實例化表示FI的類時,請使用工廠模式來創建關鍵圖形接口的實例。也就是說,您決定使用FI實例creaton來計算哪個方法,然後FI實例知道如何計算FI的關鍵值。工廠模式的優點在於,您可以額外考慮您正在計算的書籍以及其他參數,如果需要的話,即使在運行時也是如此。工廠會讓價格關鍵圖形界面簡單地指向與上下文相關的實例。

  • 然後,您稱之爲調用服務的計算機將會調用價格關鍵figue接口的方法,但接口指向的實例由FI實例提供,因爲工廠已簡單地映射價格界面的清潔價格界面或骯髒的價格界面取決於什麼是正確的具體情況下特定的FI。

如果你使用,如建議,在FI實例相關的關鍵數據和關鍵數字計算的接口實現的列表,你可以即使FI被重新分配,而不必刪除更新在運行時/交換這種/重新創建FI實例。

希望我沒有讓你的問題比實際情況更復雜。

問候,

托馬斯

0

您是否需要單獨計算器服務?如果不是如此:

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; 
    } 
} 

如果您沒有緩存價格,您甚至可能不需要本地私有變量。

調用者只需在任何實例(FinancialInstrument或CleanFinancialInstrument)上調用getPrice(),而不必擔心它是哪種類型。

hth。