在一個類中混合流暢和非流暢的接口

我認爲流暢的接口對於很多任務來說非常方便。但當我最終在一個課程中混合流利的方法和修改方法時，我感到不安。在一個類中混合流暢和非流暢的接口

只是一個例子（這是一個有點做作，請多多包涵）：

假設一個字符串的工具類，微調似乎不錯的鏈接：

Str & Str::Trim() { return TrimLeft().TrimRight(); }

其他方法自然會返回一個新對象：

Str Str::GetFirstToken() const 
{ 
    // result = first token; 
    return result; 
}

而且看到一隻3型，即 - 本身 - 邏輯上發生變異的對象和 RET甕一個新問題：

Str Str::SplitFirstToken() 
{ 
    result = GetFirstToken(); 
    // this = remainder 
    return result; 
}

當我使用是最明顯的每個方法單獨簽名，我結束了這三種類型，恐怕它並不適合消費類，這是它非常直觀，特別是因爲返回類型是mroe或更少。

我已經決定不使Str不變的 - 因爲像SplitToken方法提供核心功能。我的主要問題是混合流利的方法你會做什麼？

不要用流利的方法在接口
它們移動到一個子接口（見下文）
「如果一個流暢，所有的修改方法應流利」？
爲流利的方法使用seocific前綴？
不用擔心？
???

子接口的想法：

void CStr::Trim() { TrimLeft(); TrimRight(); } 
CStrFluent & Str::Fluent() { return CStrFluent(*this); } 
.... 
str.Fluent().TrimLeft().TrimRight();

我對這個拿不定主意，我真的不喜歡額外的「流利」 - 尤其是它在C++

什麼方法調用您認爲？

我在這裏使用了「流利」這個詞，它是在單個實例上鍊接方法調用的基本含義，而不是在代碼中創建英語句子的高級意義上。

來源

2009-07-06 peterchen

我沒有用流暢的界面做過很多工作（儘管我一般都玩過DSL），但在我看來，儘管類可能適合這種方法，但在這種情況下並不是特別必要。也許我錯過了一些東西，但是在我看來，你不可能在一個字符串上做一堆動作，而沒有引用其他任何東西，這就是你在這裏結束的東西。此外，你過渡到新的對象鏈，這似乎又違反了一個流暢的界面的目的，特別是當你考慮這個鏈條會發生什麼中間：

Str String = OtherString.GetFirstToken().SplitFirstToken().Trim();

我想也許是這種相對較低級別的實用程序類是嘗試流暢接口的錯誤地方。當你的對象受到持續的，專注的關注時，流暢性似乎比在覈心邏輯的瞬態和輔助時更重要。

來源

2009-07-08 16:27:52

「你正在過渡到鏈中間的新對象」 - 這正是我關心的核心，說得好！我會盡量擺脫現在沒有鏈接，雖然firstName = line.SplitToken（...）。修剪（）似乎是一個規範的事情。 – peterchen 2009-07-08 18:21:42

在一個類中混合流暢和非流暢的接口

回答

相關問題