這個建議來自Joshua Bloch的“Provide Programmatic Access to All Data Available in String Form”。我這裏以他的提綱爲基礎然後結合自己的理解寫了這篇短文。
這個建議的意思是如果你寫一個模塊就要把模塊裏面可以公開的數據信息以String形式提供給客戶。因爲如果你不提供這樣的String訪問接口，那麼這個使用這個模塊的客戶要得到一些這個模塊信息的時候會感到很不方便。更糟糕的是可能他自己去解析能夠得到的String信息。很多時候這個String就是來自toString()的返回。
他舉了個例子就是java.lang.Throwable.getStackTrace()。
這裏的getStackTrace()就是很好的例子。當你抓到一個Throwable(一般就是Exception)就可以調getStackTrace()得到StackTraceElement數組，然後用循環把異常的詳細信息以String的形式展現出來。而且客戶還可以用StackTraceElement的函數對每個StackTraceElement來獲取信息。如果沒有這個getStackTrace()，用戶就要自己從printStackTrace()裏面去解析異常的詳細信息，解析這個棧的確讓人很痛苦。如果說用toString()，您試一下，它只能打出當前棧頂元素的信息。
這裏我認爲值得強調的是2個地方，一個是"All Data Available"裏面的"All"，另一個"Available"。先說All，因爲你不能假設你的客戶代碼會永遠不訪問某個數據，因此要把所有的數據信息都提供出來，也就是做+法。再說Available，這個意思是要訪問權限最小化，這也是OO的一個原則，這就是個-法。舉個例子，譬如大家都知道ArrayList是由數組實現的，而這個數組的真實大小是小於等於size()的。這個時候要不要提供這個數組的長度的方法呢？當然不要，因爲這不是List接口要求，對ArrayList來說用戶也不需要關心。
翻看自己以前寫過的代碼，啊，很多沒有遵循這個規則。有些是把所有信息都寫到toString()，以至於客戶代碼要解析toString()的字符。還有些就算是寫了toString()也沒有涵蓋所有的公開信息。很多信息都是在客戶代碼裏面解析實現。因爲這樣的String一般都是給人看的，所以這樣的痛苦的代碼都是在寫log的時候用的。當他們要在log裏面打印這個對象信息的時候，get這個字段，get那個字段，然後判斷邏輯最後組成String。 這原本是這個類自己的職責。