類型

類（class），類型(type)，介面（interface）以及契約（contract）。這裡我們說到的類型和上面提到的類型有所不同，是狹義的OOP中的類型。為了理解這幾個概念，我先劃分出三個概念域：一個是針對現實世界的，一個是針對特定程序設計范型的（在這裡就是OO設計范型），最後一個是針對編譯器實現的。也就是說，在現實世界中的概念必須有一種手段映射到OO范型中去，而OO范型中的概念也應該在編譯器實現中有相同的概念對應。由此，我們可以這樣說，類是做為現實世界中的概念，而傳統的OOPL都會提供class關鍵字來表示對現實世界模擬的支持。而介面，是作為OO程序設計范型中與類對應的一個概念。在OO設計中，我們所要做的就是針對介面進行設計和編程，而介面的實質含義就是對象之間的一種契約。而類型就是編譯器實現中針對類和介面所定義的對應概念。可以這樣說，類是現實世界中存在的客觀概念，是唯物的。介面是設計人員定義出來的，存在於設計人員心中的概念，是唯心的。而類型是類和介面這兩種概念的編譯器實現的映射概念，也是唯物的。類型主要是用來指導編譯器的類型檢查的謂詞，類是創建現實對象的模板，介面是OO設計中的關鍵概念。這三個概念相互區別（分別位於不同的概念域），又相互聯繫（都是代表相同的概念的不同概念域的映射）。有了上面的理解，我們看看下面最常見的Java語句：

people a=new man();

這代表了什麼？程序員向編譯器聲明了一個people類型（type）的對象變數a，而對象變數a本身卻指向了一個man類（class）的實體（而在編譯器中理解是對象變數a指向了一個類型為man的實體）。

在面向對象設計（OOD）中，“歸類”是重要步驟，一個精心設計的類層次結構是則是OOD的重要成果。類的層次和界面定義得好，將造福軟體系統的實現者、維護者和以後的擴展者：他們會驚喜地發現，許多錯綜複雜的關係在清晰的類型層次中不言自明；而失敗的類層次結構則是災難的來源：為了繞過不合理的類型設計帶來的束縛，編碼員不得不把各種能想到的技巧都用了上去——包括強制的類型cast、直接對對象內存的訪問等，而這些技巧往往和潛在的bug形影相隨。

再讓我們回到【Jams 2000】，其中句子的根本含義我們可以概括如下：

聲明一個類或者一個介面都同時向編譯器註冊了一個新的類型，而此類或者介面以及類型都是共享同樣的一個名字。也就是說。編譯器所能理解的全部都是類型，而程序員的工作是把現實中的類概念轉化為設計中的介面概念，而編譯器對應於上兩種概念都有直接的支持，那就是一個類聲明或者介面聲明在編譯器的理解來看就是一個類型聲明。但是反過來卻不一定成立。一個類可以有多個介面，（一個類完全有可能實現了設計人員的多個契約條件），同時也就可能有多個類型（因為類型不過是介面這個設計域內的概念在編譯器中的實現）。