「类型」修訂間的差異檢視原始碼討論檢視歷史
（创建页面，内容为“{{Infobox person | 姓名 = '''类型''' | 图像 = File:类型.png|缩略图||center|[http://www.cq.xinhuanet.com/2018-04/04/1122638432_1522826072630…”） |
|||
| 行 4： | 行 4： | ||
[[File:类型.png|缩略图||center|[http://www.cq.xinhuanet.com/2018-04/04/1122638432_15228260726301n.png 原图链接] [http://www.xinhuanet.com/webSkipping.htm 来自新华网]]] | [[File:类型.png|缩略图||center|[http://www.cq.xinhuanet.com/2018-04/04/1122638432_15228260726301n.png 原图链接] [http://www.xinhuanet.com/webSkipping.htm 来自新华网]]] | ||
}} | }} | ||
| − | '''<big>类型</big>'''，以及类型系统的起源以及研究与发展是独立于OOP的。早在五十年代的FORTRAN语言编译器实现中，就已经采用类型系统作为类型检查的一种手段。广义的类型一般被定义为一种约束，也就是一种逻辑公式。而在对类型的研究过程中产生多种方法，比如【C&W 1985】等。<ref>[https://www.360kuai.com/pc/9484e7d425d8698ef?cota=3&kuai_so=1&sign=360_57c3bbd1&refer_scene=so_1 恐惧症的三种类型]</ref> | + | '''<big>类型</big>'''('''英語: type''' ) ，以及类型系统的起源以及研究与发展是独立于OOP的。早在五十年代的FORTRAN语言编译器实现中，就已经采用类型系统作为类型检查的一种手段。广义的类型一般被定义为一种约束，也就是一种逻辑公式。而在对类型的研究过程中产生多种方法，比如【C&W 1985】等。<ref>[https://www.360kuai.com/pc/9484e7d425d8698ef?cota=3&kuai_so=1&sign=360_57c3bbd1&refer_scene=so_1 恐惧症的三种类型]</ref> |
而[[代数方法]](algebraic approach)是一种非常好的建立类型的形式化规范的方法。代数中的一个类型对应于一系列元素，在它们之上定义代数操作。同时在此基础上二阶λ演算已经被用于继承和模板所支持的模型。在上面两种方法中，类型被认为是一系列满足确定约束条件的元素，更抽象的方式可以把一个类型当作规定一个约束条件，如果我们规定的约束条件越好， | 而[[代数方法]](algebraic approach)是一种非常好的建立类型的形式化规范的方法。代数中的一个类型对应于一系列元素，在它们之上定义代数操作。同时在此基础上二阶λ演算已经被用于继承和模板所支持的模型。在上面两种方法中，类型被认为是一系列满足确定约束条件的元素，更抽象的方式可以把一个类型当作规定一个约束条件，如果我们规定的约束条件越好， | ||
於 2022年9月9日 (五) 10:04 的最新修訂
| 類型 | |
|---|---|
類型(英語: type )，以及類型系統的起源以及研究與發展是獨立於OOP的。早在五十年代的FORTRAN語言編譯器實現中，就已經採用類型系統作為類型檢查的一種手段。廣義的類型一般被定義為一種約束，也就是一種邏輯公式。而在對類型的研究過程中產生多種方法，比如【C&W 1985】等。[1] 而代數方法(algebraic approach)是一種非常好的建立類型的形式化規範的方法。代數中的一個類型對應於一系列元素，在它們之上定義代數操作。同時在此基礎上二階λ演算已經被用於繼承和模板所支持的模型。在上面兩種方法中，類型被認為是一系列滿足確定約束條件的元素，更抽象的方式可以把一個類型當作規定一個約束條件，如果我們規定的約束條件越好，
相對應的被定義元素的集合就越精密，所以邏輯公式(logical formulas)就成為描述類型特徵的最合適工具。在這裡，我們不想深入的探究對於類型理論的各種不同的數學模型，我們需要明白的是類型(type)以及類型理論這個在編程語言中經常應用到的概念的內涵是極其豐富的，而其自身理論的發展並非局限於OOP之中，但當兩者相結合的時候就對我們的程序觀產生了巨大的影響。
基本信息
中文名稱 類型 [2] 外文名稱 type
廣義 一般被定義為一種約束
特點 其研究與發展是獨立於OOP的
四個概念
類(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】，其中句子的根本含義我們可以概括如下:
聲明一個類或者一個接口都同時向編譯器註冊了一個新的類型，而此類或者接口以及類型都是共享同樣的一個名字。也就是說。編譯器所能理解的全部都是類型，而程序員的工作是把現實中的類概念轉化為設計中的接口概念，而編譯器對應於上兩種概念都有直接的支持，那就是一個類聲明或者接口聲明在編譯器的理解來看就是一個類型聲明。
但是反過來卻不一定成立。一個類可以有多個接口，(一個類完全有可能實現了設計人員的多個契約條件)，同時也就可能有多個類型(因為類型不過是接口這個設計域內的概念在編譯器中的實現)。