技術名詞紛爭多

在程式開發的世界中，充滿了各種名詞，有些定義清楚，然而也有許多名詞，只是為了簡單描繪提出者想敘述的東西，而被臨時創造出來。

這些名詞通常沒有明確的定義，一開始只是為了溝通方便，而隨著聽聞者各自的領會與轉述，加上時間與歷史的推移，它們的定義會發生岐義而各自發展，最後失去了溝通的意義。

各持己見的名詞之爭

最近網路上有篇〈MVC是一個巨大誤會〉引起了許多人的爭論，文章本身的動機在試圖搞清楚，為什麼大家說的MVC都不太一樣？開發者發現正在實作的MVC，為何與某些文件講的MVC不同？因而展開了一場精采的探索之旅。

有幸地，文中也引用了我先前專欄〈MVC與Model 2的變異與結合〉作為延伸閱讀，結論是終於搞清楚MVC了，不過，許多網友的回應中卻指出，該文作者在談的MVC好像並不是MVC？

在〈MVC與Model 2的變異與結合〉中，其實可以看到，MVC這個名詞有著一段歷史發展過程，而在這段過程中，前前後後有人試圖去學習、瞭解MVC，而每個人擷取到的，都是這個歷史發展過程中某個時間對MVC的定義或實作，當兩個開發者用兩個不同時間點的定義或實作嘗試進行溝通時，就會發生隔閡，實際上，這種情況在程式開發的世界中，一直重複不斷地發生著。

舉我先前專欄〈private繼承之爭〉來說好了，private成員到底會不會被繼承？在許多討論區中，都曾戰上一回。繼承這名詞，老實說也沒有精確的定義，我試著瞭解每個人的說法，並調查可搜尋到的文件後，發現大家講的其實是兩種不同定義的繼承，也就是「介面繼承」與「實作繼承」，因為沒有去瞭解彼此講的是何種繼承，才會導致兩造各說各話的局面。

如果有人說，函式可以擁有相同的名稱，但參數不同，這個行為是多型，你會予以反駁呢？有人會說這不是多型，而是重載（Overload），如果有人說泛型是一種多型呢？大概不能接受的人也很多。

歷史上，對多型也有不同定義，重載被視為特定（Ad-hoc）多型的一種實現，泛型可被視為一種參數（Parametric）多型的實現，而後者在Haskell是自然且常見的實現，因此都直接稱多型。我先前專欄〈多型的本質〉有三篇文章（請參考：多型的本質（一）、多型的本質（二）、多型的本質（三）），就討論過這幾個多型，歷史上的多型還不只有這三個，如果硬是要用大家較熟悉的次型態（Subtype）多型，來說重載、泛型不是多型，實在不是使用這些名詞之目的。

某些程度上，在遇到有岐義且引發爭議的名詞時，我還滿愛挖墳考古、探究名詞之起源，因為程式開發界，並不是每個名詞都有精確定義，往往隨著歷史的演變，而有不同的解釋，而我喜歡知道這些解釋是怎麼來的，這樣就可以在有人為某個名詞而爭論時，試著瞭解他在講的可能是歷史上的那種解釋，就算我挖到名詞最初發源的人、事、時、地、物，目的也不在於用這來否定對方的說詞。

舉例來說，同樣是名詞之爭，Java界的Spring框架當初也面臨過，因為它聲稱自己的核心是IoC（Inversion of Control）的實現，在它的文件中指出，這是因為Bean對其相依物件的生成、位置之控制權，反過來被容器（Container）來控制以注入（Inject）的方式實行，不過，有人認為IoC應是指流程的控制權，從開發者手中轉移至框架，而不是指相依物件的控制權被轉移。為此，Martin Fowler建議採用DI（Dependency injection）來取代IoC一詞，以平息對IoC的紛爭。

探索IoC名詞的過程中，我看到Martin Fowler在〈Inversion of Control Containers and the Dependency Injection patter〉中有著這樣的說法，最終目的並不是讓我可以指著別人鼻子說：「Spring並不是實現IoC容器，而是DI容器」，而是清楚地知道，當有人說Spring核心是IoC容器，他指的是Bean對相依物件的控制權被轉移這回事，而不是指流程控制權被轉移至框架，我們因此得以繼續用相同觀點溝通，而非摸不清對方在講些什麼。

隨意創造、濫用名詞的世界

程式開發的世界中，名詞的創造經常是隨意的，曾經在Java中爭執不斷的考古題之一是：「Java中有沒有Pass by reference」，就現今來說，大家公認的答案是沒有，Java只有Pass by value，不過還是有人面對Java文件中經常出現reference，而搞不清楚。

說穿了，這個名詞與C++中的reference定義不同，只不過Java最初不知道為什麼，也用了reference一詞，重點也不在搞清楚Pass by value，重點是搞清楚透過參數操作物件時，會有什麼樣的行為。

物件導向的世界更是個名詞王國，實際上物件導向的準確定義與目的也一直存在著不少爭論。

就歷史來看，雛形出現在1960年的Simula語言，它引入了類別的概念，而被視為物件導向語言基礎的Smalltalk，引入了繼承的概念，那麼只有具備類別的語言，才是物件導向嗎？JavaScript也是物件導向語言，即使它沒有類別，但具有物件，也能實現繼承，它不是Class-based OOP，而是Prototype-based OOP。

就我可找到的資料來看，Self也是Prototype-based OOP的語言之一，沿用了Smalltalk中一切都是物件的風格，但取消了類別的概念……想搞清楚這些歷史彼此間的連結，本身就夠混亂了，更別說名詞定義的轉變了。

好吧！確實是有人會在提出一個名詞之前，先為名詞做好定義，Gof（Gang of four）的《Design Pattern》書中，就先為設計模式是什麼而做了定義──一個模式包括了模式名稱（pattern name）、問題（problem）、方案（solution）與結論（consequences）四個部份，不過，有幾個開發者在使用或描述一個模式時，會完整照著這四個部分來思考或溝通？

大多數的情況下，開發者就是對某個模式名詞有個概念，然後試著實作它或拿它來溝通，而常見的溝通不良，像是「這不是XXX模式，你沒有如何如何……」的爭論，就發生了。Gof的書中對模式的第四個部份也說到：「結論是套用模式之後的結果或折衷」因為使用某個模式概念，針對實際處理的問題實作出來的方案，必然會有不同的調整與結果，只是現在常見的是，即使設計模式書中有這四個部分的定義，在發生爭論時，多半也是隨意地取其中一二來各持已見。

放棄令你壁壘分明的名詞

回過頭來看MVC之爭，因為文中延伸閱讀提到了我的專欄文章，看來我的觀點與作者是一致的？不！分清楚MVC與Model2並不是我那篇文章的目的，否則，也不會有「1999年Govind Seshadri在Javaworld發表了《Understanding JavaServer Pages Model 2 architecture》文章，其影響之一是將Model 2界定為架構模式，第二個影響是確立Model 2為Web應用程式提供了一種MVC架構」這段話，如果我的目的是想分清楚MVC與Model2，那這段話根本就是自打嘴巴！

挖墳考古的目的，不是為了要將找出來的名詞定義奉為圭臬，而是清楚名詞的發展過程，瞭解到彼此溝通時，可能發生了哪些誤會，希望能說出：「我知道你談的XXX是什麼」這樣的話，重點並不在XXX為何，而是因為我探究過這段歷史與這些變異，因而能與對方更好的溝通，而不是吵架。

在《松本行弘的程式設計世界》的〈語彙與共通語言的重要性〉這篇文章中，作者談到，為某個概念決定適當的名詞，目的是在設計時能有共同的語彙，也能讓開發者意識到它們的存在，這才是名詞存在的真正意義。在我看來，如果釐清某些名詞，只是為了壁壘分明，那乾脆就不要這些名詞！