## 本章小結 Java為固定大小的低級數組提供了合理的支持。這種數組強調的是性能而不是靈活性，就像C和c++數組模型一樣。在Java的最初版本中，固定大小的低級數組是絕對必要的，這不僅是因為Java設計人員選擇包含原生類型(也考慮到性能)，還因為那個版本對集合的支持非常少。因此，在早期的Java版本中，選擇數組總是合理的。 在Java的后續版本中，集合支持得到了顯著的改進，現在集合在除性能外的所有方面都優于數組，即使這樣，集合的性能也得到了顯著的改進。正如本書其他部分所述，無論如何，性能問題通常不會出現在您設想的地方。 使用自動裝箱和泛型，在集合中保存原生類型是毫不費力的，這進一步鼓勵您用集合替換低級數組。由于泛型產生類型安全的集合，數組在這方面也不再有優勢。 如本章所述，當您嘗試使用泛型時，您將看到泛型對數組是相當不友好的。通常，即使可以讓泛型和數組以某種形式一起工作(在下一章中您將看到)，在編譯期間仍然會出現“unchecked”警告。 有幾次，當我們討論特定的例子時，我直接從Java語言設計人員那里聽到我應該使用集合而不是數組(我使用數組來演示特定的技術，所以我沒有這個選項)。 所有這些問題都表明，在使用Java的最新版本進行編程時，應該“優先選擇集合而不是數組”。只有當您證明性能是一個問題(并且切換到一個數組實際上會有很大的不同)時，才應該重構到數組。這是一個相當大膽的聲明，但是有些語言根本沒有固定大小的低級數組。它們只有可調整大小的集合，而且比C/C++/java風格的數組功能多得多。例如，Python有一個使用基本數組語法的列表類型，但是具有更大的功能—您甚至可以從它繼承: ```Python # arrays/PythonLists.py aList=[1,2,3,4,5]print(type(aList)) #<type 'list'> print(aList) # [1,2,3,4,5] print(aList[4]) # 5Basic list indexing aList.append(6) # lists can be resized aList+=[7,8] # Add a list to a list print(aList) # [1,2,3,4,5,6,7,8] aSlice=aList[2:4] print(aSlice) # [3,4] class MyList(list): # Inherit from list # Define a method;'this'pointer is explicit: def getReversed(self): reversed=self[:] # Copy list using slices reversed.reverse() # Built-in list method return reversed # No'new'necessary for object creation: list2=MyList(aList) print(type(list2)) #<class '__main__.MyList'> print(list2.getReversed()) # [8,7,6,5,4,3,2,1] output=""" <class 'list'> [1, 2, 3, 4, 5] 5 [1, 2, 3, 4, 5, 6, 7, 8] [3, 4] <class '__main__.MyList'> [8, 7, 6, 5, 4, 3, 2, 1] """ ``` 前一章介紹了基本的Python語法。在這里，通過用方括號包圍以逗號分隔的對象序列來創建列表。結果是一個運行時類型為list的對象(print語句的輸出顯示為同一行中的注釋)。打印列表的結果與在Java中使用Arrays.toString()的結果相同。 通過將 : 操作符放在索引操作中，通過切片來創建列表的子序列。list類型有更多的內置操作，通常只需要序列類型。 MyList是一個類定義;基類放在括號內。在類內部，def語句生成方法，該方法的第一個參數在Java中自動與之等價，除了在Python中它是顯式的，而且標識符self是按約定使用的(它不是關鍵字)。注意構造函數是如何自動繼承的。 雖然一切在Python中真的是一個對象(包括整數和浮點類型),你仍然有一個安全門,因為你可以優化性能關鍵型的部分代碼編寫擴展的C, c++或使用特殊的工具設計容易加速您的Python代碼(有很多)。通過這種方式，可以在不影響性能改進的情況下保持對象的純度。 PHP甚至更進一步，它只有一個數組類型，既充當int索引數組，又充當關聯數組(Map)。 在經歷了這么多年的Java發展之后，我們可以很有趣地推測，如果重新開始，設計人員是否會將原生類型和低級數組放在該語言中(同樣在JVM上運行的Scala語言不包括這些)。如果不考慮這些，就有可能開發出一種真正純粹的面向對象語言(盡管有這樣的說法，Java并不是一種純粹的面向對象語言，這正是因為它的底層缺陷)。關于效率的最初爭論總是令人信服的，但是隨著時間的推移，我們已經看到了從這個想法向更高層次的組件(如集合)的演進。此外，如果集合可以像在某些語言中一樣構建到核心語言中，那么編譯器就有更好的機會進行優化。 撇開““Green-fields”的推測不談，我們肯定會被數組所困擾，當你閱讀代碼時就會看到它們。然而，集合幾乎總是更好的選擇。