`decorator'類的好名字？

我想將我正在處理的API分成兩部分：'裸骨'和'輕鬆'。這個想法是，'cushy'部分中的所有方法調用都可以用'bare-bones'部分中的方法來表示，也就是說，它們只能作爲快速和骯髒的便捷方法。我想這樣做的原因是，當人們第一次開始使用API時，他們對細節和性能不感興趣：他們只是想讓它工作。`decorator'類的好名字？

以前有人試過類似的東西嗎？我對命名約定和組織代碼特別感興趣。

來源

2010-03-13 Lajos Nagy

我會避免單詞「裝飾」，因爲這是一個相當不同的設計模式。我認爲這可能被稱爲門面模式。 –

有人在工作建議Foo和FooHelper。我喜歡。

來源

2010-03-19 15:29:32

'助手'並沒有告訴我很多：我必須有一個'Foo'，然後如果我需要一個，我可以抓住一個'FooHelper'？沒有'Foo'有沒有可能有'FooHelper'？不是說我自己並沒有使用'助手'，但它並沒有真正幫助我弄清楚我應該做什麼。 –

既然你要求好名字，常用的是簡單或基本的API和擴展API。正如Simon Nickerson所提到的，簡單的API在技術上通過提供抽象來使用擴展的API。另請參閱Facade Pattern

來源

2010-03-13 18:34:10 stacker

提供「輕鬆」與「裸露骨骼」的離散分離的一種方法是使用由同一類實現的單獨接口。編寫API時，我希望儘可能簡單。如果您需要大量參數，請考慮使用fluent interface。

來源

2010-03-13 18:55:53 Ryan

是的，我之前做過這樣的事情，而且我傾向於預先指出一個詞，指出額外的功能在做什麼。

例如，一個基本的Vector類可能只執行非常基本的向量操作（add，dot product），並且類可能有多種靜態輔助方法（交叉產品，投影等）。然後，一個FluentVector包含所有這些幫助操作，同時突變底層Vector。

但是，這不是裝飾模式 - 裝飾使用相同的接口產生不同的「裝飾」結果。這是門面模式 - 具有相同底層功能的不同界面。

另外，請記住，您的擴展API可能有多種不同的方式來提供相同的功能。回到我的Vector的例子，人們可能不希望在每個鏈接操作中對基本的Vector進行變異，而是引入新的Vector--這可能是ImmutableFluentVector或其他一些。該API將是相同的，除了規範的副作用。只是要記住。

來源

2010-03-13 19:29:45 Carl

假設準系統提供了基本的功能性和輕鬆的提供額外的功能：


public class Skeleton 
{ 
    public virtual void Info() 
    { 
    } 
} 

public class Adorner:Skeleton 
{ 
    private Skeleton _skeleton; 

    public Adorner(Skeleton skeleton) 
    { 
    _skeleton = skeleton; 
    } 

    public override void Info() 
    { 
    //apply adorning work 
    } 
}

骨架準系統=新骨架（）; Adorner cushy = new Adorner（bareBones）;

來源

2010-03-23 09:27:06 RockWorld

`decorator'類的好名字？

回答

相關問題