基於自然語言的軟體工程和程式設計（下）

軟體發展至今，無論是程式設計語言，還是軟體工程，乃至是互連網的趨勢發展，都是飛速發展。於是，我們便迷茫於這樣形形色色的語言和概念之間，無所適從。其實，我們不妨返璞歸真，回到最初，讓我們從語義出發，來討論這形形色色的種種，你是否恍然大悟呢？

前文索引：

基於自然語言的軟體工程和程式設計（上）

基於自然語言的軟體工程和程式設計（中）

10. 物件導向與語義分析

我們都知道，物件導向是自頂向下的分析過程和自底向上的設計過程。在這裡，首先，我們先不談分析過程，只談設計過程。

系統有多少個類，不是一拍腦袋想出來的，不是經驗累積而成的，而是根據需求分析中提煉出來的。

類的產生是名詞提煉的過程，我們知道，每個對象都是對應著現實中的一個實體，而每個類都是對具有相同特徵的對象的抽象。越是恰當的抽象，我們就越能提煉出精確的類。

這時，讓我們不得不感歎古人詩詞的精妙：

枯藤老樹昏鴉，小橋流水人家，古道西風瘦馬。夕陽西下，斷腸人在天涯。

詩詞，是對文章高度的抽象過程；物件導向的設計過程，也是對現實世界的抽象過程；何時，我們能將需求分析文檔精確提煉成古詩詞，此時乃大悟物件導向之道也。

11. 設計是違反語義的過程

與其說物件導向可重用，易維護，不如說物件導向更貼近我們的現實設計，讓我們的每一個類的產生都有章可循。此乃為物件導向之妙也。

在之前的一部，我們將現實社會映射成了我們的程式中對應的類，可是這時肯定會有人跳出來說，這是物件導向嗎？繼承，多態，封裝，你這什麼都沒有啊！

這就是我在本節中要提到的，在我看來：設計是一個違反語義的過程。

例如：”老師講課，學生聽課。“這樣的語義環境，自然會產生老師和學生兩個類，可是大家這時都會想到，此時應該提取出來”人“作為老師和學生的基類（父類）。可是，我們知道，人在此語義中是不存在的，他只是我們根據經驗來假設出來的。我們在之前說過，類是對對象（現實事物）的抽象，而父類又是對類的再抽象過程。因此，我認為：繼承是對抽象的再抽象。

提到設計，我們就要提到設計模式，我們來想想常見的設計模式，工廠，適配器，策略等等，這些在我們的語義中都是無法分析出來的，因此，在我看來，設計模式實際上是犧牲了語義的自然性，來換取軟體的可重用性和可維護性。

12. 資料庫設計與自然語義的衝突

在此，我指的資料庫特指關係型資料庫。因此我說，資料庫設計與自然語義的衝突，其實就是說關係型資料庫與物件導向語言之間無可調和的矛盾。

換句話說，在物件導向中，屬性不一定是原子的，資料也不一定沒有冗餘，因此資料庫的三大範式對於物件導向設計來說，是不適用的，這也就間接導致了，關係型資料庫和物件導向設計時衝突的。

（註：由於本人對 ORM瞭解甚為，以下言論請大家選擇性相信，也希望大家不吝賜教）其中ORM就是為瞭解決物件導向與關係型資料庫不匹配而產生的技術。很多人在用ORM時有一個誤區，就是首先建立資料庫，然後由資料庫產生實體物件，但是在我看來，資料庫只應該是儲存資料的工具，而絕不應該成為整個項目設計的核心，正確使用ORM的辦法應該是把程式自動持久化到關聯式資料庫中，而我們在程式中對資料庫是一無所知的，我們操作的只是一個對象的集合罷了。我不清楚ORM當今的發展，但是在我看來，一個完美的ORM系統應該具備解析對象，然後將對象轉換為符合範式的資料庫結構的能力。

另外，視圖和緩衝表也是解決方案之一。

最後，我們只能期待對象型資料庫的進一步成熟了。

13.  我眼中的未來語言

在我眼中，語言的發展方嚮應該是逐步貼近語義，試想從第一代語言發展至今，語言的趨勢無非是越來越適合於程式員使用，提高程式員的工作效率，說句再難聽些的，就是逐步降低系統開發程式員的門檻，其體現一者在於方法封裝的逐步完善，二就在于越來越接近自然語言，越來越接近“大型作文”的寫作過程。

那麼當軟體發展到一定程度，我認為未來的語言是等同於自然語言的程式設計語言。從而人人可程式化，方法高度封裝，編譯器可識別人們的自然語言語義從而轉換成機器可識別的語言。我們需要做的只是把需求整理成“無語病”的需求分析文檔，然後把文檔移交給“編譯器”，返回給我們的是一個個.exe，.aspx。

也許到了那一天，程式員這個職業不複存在了，取而代之的是作家，這一天，我們說，軟體真的發展到了最高階段。