因為Rectangle具有可變性，上面的代碼將引起組件的改變，對于象AWT這樣的GUI工具包而言，這將是災難性的，因為當一個組件變化時，需要重新刷新屏幕，同時還需要通知事件監視程序。因此上面的Component.getBounds()的運行是相當危險的，下面所示的方式才是比較安全的：
public Rectangle getBounds() {
return new Rectangle(myBounds.x, myBounds.y,
myBounds.height, myBounds.width);
}
但是，就象RegExpMatcher那樣，每次調用getBounds()都會創建一個新的對象，下面的代碼將會創建四個臨時對象：
int x = component.getBounds().x;
int y = component.getBounds().y;
int h = component.getBounds().height;
int w = component.getBounds().width;
對于String類而言，創建對象是必要的，因為String是不可變的。但是在這個例子中，創建臨時對象似乎也是必需的，因為Rectangle具有可變性，我們可以通過不在接口中使用任何對象來避免象String引起的那樣的問題。盡管在與RegExpMatcher類似的場合中，這一方案并非總是可行的或理想的，然而，幸運的是，在設計類時可以采用一些技術，既能使用小一些的對象又不會遇到使用太多的小對象所引起的問題。
數據類型對軟件性能的影響
BadRegExpMatcher要求MailBot將輸入文本由字符數組轉換為一個String對象，從而導致了不必要的對象創建。然而，滑稽的是為了更方便地使用輸入文本，BadRegExpMatcher會立即將String對象轉換為一個字符數組，這樣不但會生成另一個對象，還意味著你在費了九牛二虎之力得到的結果，跟調用程序最初提供的數據沒有什么二樣，MailBot和BadRegExpMatcher都不要求使用String對象，String對象似乎僅僅是為也在組件之間交換文本數據而存在的。
在上面的BadRegExpMatcher例子中，String僅僅是一種供交換用的類型，無論是調用程序還是被調用程序都不需要使用供交換用的數據類型來表示數據，但它們可以很方便地把它與其他的數據類型進行轉換。盡管在定義接口時采用供交換用的數據類型可以在保持靈活性的前提下降低復雜性，但有時會帶來性能上的損失。
供交換用數據類型的一個最常見的例子是JDBC ResultSet接口，沒有一種數據庫的接口會用JDBC ResultSet表示返回的結果，但JDBC驅動程序可以很方便地把數據庫返回的結果轉換為JDBC ResultSet型數據。同樣，也沒有一種客戶端軟件用DBC ResultSet型數據表示數據記錄，但你也可以不費什么勁兒就將ResultSet型數據轉換為所需要的數據類型。在JDBC中我們可以接受這種"多此一舉"，因為它具有標準性和跨數據庫的可移植性等好處。無論如何，由供交換用數據類型所帶來的性能損失都是一個值得注意的問題。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
