可以看到TListBoxStrings在內部並沒有保存添加的字符串，而是直接向Windows的原生列表盒控件發送消息實現的代碼添加，而Windows的原生列表盒是一個MVC的組件，當內部的數據發生變化時，會自動改變視圖顯示，這就是為什麼我們在設計器中輸入的字符串會立刻顯示在窗體列表框中的原因了。
於是我們也就知道為什麼Borland將TStrings設計為一個抽象的類而沒有提供一個默認的存儲方式，就是因為很多的界面組件在內部對數據的存儲有很多不同的方式，Borland決定針對不同的組件提供不同的存儲和交互方式。同樣的我們要編寫的組件如果有TStrings類型的屬性，同時也要同界面或者其它資源交互的話，不要使用TStringList來實現，而應該從TStrings派生出新類來實現更好的交互設計。
還有一點要說明的是，Delphi的IDE只在使用Delphi的流機制保存組件到窗體設計文件DFM文件中的時，做了一些特殊的處理，能夠自動保存和加載Published的TStrings類型的屬性，下面就是一個ListBox儲存在窗體設計文件DFM中文本形式示意(在窗體設計階段，我們可以直接使用VIEw As Text右鍵菜單命令看到下面的文本)，我們可以注意到在設計時我們輸入的Items的兩個字符串被保存了起來：
object ListBox1: TListBox
Left = 64
Top = 40
Width = 145
Height = 73
ItemHeight = 16
Items.Strings = (
'String1'
'String2')
TabOrder = 1
end
隨後如果運行程序時，VCL庫會使用流從編譯進可執行文件的DFM資源中將Items.Strings列表加載到界面上，這樣就實現了設計是什麼樣，運行時也是什麼樣的所見即所得。
鍵-值對
在實際開發過程中，我們經常會碰到類似於字典的定位操作的通過鍵查找相應值的操作，比如通過用戶名查找用戶相應的登陸密碼等。在C++和Java中，標准模版庫和JDK都提供了Map類來實現鍵-值機制，但是Delphi的VCL庫卻沒有提供這樣的類，但是TStrings類提供了一個簡易的Map替代的實現，那就是Name-Value對。
對於TStrings來說，所謂的Name-Value對，實際上就是’Key=Value’這樣包含＝號的分割的字符串，等號左邊的部分就是Name，等號右邊的部分就是Value。TStrings類提供了IndexOfName和Values等屬性方法來操作Name-Value對。下面是用法示意：
var
StringList1:TStrings;
Begin
StringList1:=TStringList.Create;
//添加用戶名-密碼對
StringList1.Add(‘hubdog=aaa’);
StringList1.Add(‘hubcat=bbb’);
….
//根據用戶名hubdog查找密碼
Showmessage(StringList1.Values[StringList1.IndexOfName(‘hubdog’)]);
End;
從Delphi7開始，TStrings類增加了一個NameValueSeparator屬性，我們可以通過這個屬性修改默認的Name-Value分割符號為=號以外的其它符號了。還要說明的是，TStrings的Name-Value對中的Name可以不唯一，這有點類似於C++中的MultiMap，這時通過Values[Names[IndexOfName]]下標操作取到的值不一定是我們所需要的，另外TStrings類的Name-Value對的查找定位是采用的遍歷的方式，而不同於Java和C++中的Map是基於哈希表或者樹的實現，因此查找和定位的效率非常低，不適用於性能要求非常高的場景。不過從Delphi6開始,VCL庫中在IniFiles單元中提供了一個基於哈希表的字符串列表類THashedStringList類可以極大的提高查找定位的速度。
