胡思亂想–關於cpp中非成員函數的擴充

今天從圖書館借了本Herb Sutter的《Exceptional C++ Style》，Herb在這本書的最後專門整了個專題來討論std::string的設計問題，其中的核心內容就是討論給std::string瘦身，更進一步，Herb提出了他的觀點--“為了避免巨型(monolithic)設計，儘可能編寫非成員非友元形式的函數”。

Herb認為如果一個class總是試圖通過成員函數而不是非成員函數來提供功能 ，將會有兩個主要的問題:

1. (主要問題)把可能獨立可用的功能"封鎖"在了一個類的內部
2. (次要問題)這種設計可能會阻礙你為一個類擴充出新功能

不過根據自己實際使用中的一點感受，我恐怕還就是更趨向於成員函數。o，慢點，沒搞錯吧？是的，我的理由其實很簡單，因為對於一個member function，幾乎的所有的IDE都支援一個看似簡單，但是非常有效小trick--智能感知(intelli-sense)。然而對於C++中的一個非成員的函數，IDE是無能為力的。看看STL裡面有那麼多的標準用法，但實際當中很多人卻還要去重複實現自己的版本，恐怕也有這方面的原因。畢竟容器就那麼幾個，瞭解一下也許還不是太費勁，但是各種演算法、運算元量就太多了，要想一一瞭解還真不是那麼容易

一個Class裡面涉及到的相關操作可能很多(像std::string就有超過一百個的成員函數)，要清楚的瞭解所涉及的所有操作實在是很難。誠然，作為一個勤勞的程式員，你也許會說這不是問題，document就安靜的躺在你的硬碟上，再加上無所不能的Google，理論上完全可以掌握所有的操作，不管是成員函數還是非成員函數。但是有一點可以肯定，如果這個函數是成員函數，用起來恐怕要爽的多--首先有IDE的智能感知的支援，如果不會用，ok，在文檔裡面很輕鬆的就可以找到詳盡的描述。而如果是非成員的，那就糟糕了，三找兩找都找不到，要知道程式員也有急躁的時候，好吧，乾脆放棄搜尋行動，就一個函數嘛，我自己也能實現的...但事實往往不那麼簡單:(

回到Herb的討論中，是Herb錯了嗎？當然不是，他的兩個觀點都是很有道理的。那是我們錯了嗎，好像也很難這麼講，IDE確實對這種非成員函數無能為力呀!作為一個coder，我就不能有一點小小的要求嗎？

那麼我們現在就來YY以下，有沒有可能為C++的IDE增加這種支援非成員函數與對象邦定的intelli sense功能？完全可以，在這個問題上，C# 3.0已經給C++作了一個很好的典範。為了支援LINQ技術，Anders為C#引入了Extension Methods，如下面代碼：

namespace System.Query
{    
 public static class Sequence    
 {        
  public static IEnumerable<T> Where<T>(this IEnumerable<T> source, Func<T, bool> predicate) { … }   
  public static IEnumerable<S> Select<T, S>(this IEnumerable<T> source,  Func<T, S> selector) { … }           

  // more functions 
 }
}

在調用的程式裡，只要匯入System.Query的namespace，對於實現了IEnumerable介面的對象，就可以像成員函數一樣使用Sequence裡面的這些Select, Where...方法了，而且都是帶有智能感知功能的喲，ok，Extension Methods，就是這樣。至於底下具體的轉換工作，那是編譯器的事，我們就不管了。

實際上C++完全可以提供類似概念的extension methods，同樣運用namespace的概念，似乎我們就可以將Herb大師分析出來的std::string中的那些非成員函數放到一個namespace下，然後將這個namespace添加到std::string或者是調用端的檔案裡面，根據IDE的自動推斷，使用者使用的時候感覺就和成員函數一樣方便，只要知道std::string就可以找到想要的方法，智能感知當然也是可以提供的。而且這些方法本身還是非成員函數，代碼仍然可以被不同單元reuse。當然，修改一下編譯器還是必要的，畢竟這個翻譯過程還得由編譯器來替我們做。

貌似這樣既到達了Herb大師追求高品質設計的目的，又給我們這些懶惰的程式員提供了實際需要，perfect！

嘿嘿，全當自己YY吧:)