|
|
系列文章導航：
軟件發展至今，無論是編程語言，還是軟件工程，乃至是互聯網的趨勢發展，都是飛速發展。于是，我們便迷茫于這樣形形色色的語言和概念之間，無所適從。其實，我們不妨返璞歸真，回到最初，讓我們從語義出發，來討論這形形色色的種種，你是否恍然大悟呢？
10. 面向對象與語義分析
我們都知道，面向對象是自頂向下的分析過程和自底向上的設計過程。在這里，首先，我們先不談分析過程，只談設計過程。
系統有多少個類，不是一拍腦袋想出來的，不是經驗累積而成的，而是根據需求分析中提煉出來的。
類的產生是名詞提煉的過程，我們知道，每個對象都是對應著現實中的一個實體，而每個類都是對具有相同特征的對象的抽象。越是恰當的抽象，我們就越能提煉出精確的類。
這時，讓我們不得不感嘆古人詩詞的精妙：
枯藤老樹昏鴉，小橋流水人家，古道西風瘦馬。夕陽西下，斷腸人在天涯。
詩詞，是對文章高度的抽象過程；面向對象的設計過程，也是對現實世界的抽象過程；何時，我們能將需求分析文檔精確提煉成古詩詞，此時乃大悟面向對象之道也。
11. 設計是違反語義的過程
與其說面向對象可重用，易維護，不如說面向對象更貼近我們的現實設計，讓我們的每一個類的產生都有章可循。此乃為面向對象之妙也。
在之前的一部，我們將現實社會映射成了我們的程序中對應的類，可是這時肯定會有人跳出來說，這是面向對象么？繼承，多態，封裝，你這什么都沒有啊！
這就是我在本節中要提到的，在我看來：設計是一個違反語義的過程。
例如：”老師講課，學生聽課。“這樣的語義環境，自然會產生老師和學生兩個類，可是大家這時都會想到，此時應該提取出來”人“作為老師和學生的基類（父類）。可是，我們知道，人在此語義中是不存在的，他只是我們根據經驗來假設出來的。我們在之前說過，類是對對象（現實事物）的抽象，而父類又是對類的再抽象過程。因此，我認為：繼承是對抽象的再抽象。
提到設計，我們就要提到設計模式，我們來想想常見的設計模式，工廠，適配器，策略等等，這些在我們的語義中都是無法分析出來的，因此，在我看來，設計模式實際上是犧牲了語義的自然性，來換取軟件的可重用性和可維護性。
12. 數據庫設計與自然語義的沖突
在此，我指的數據庫特指關系型數據庫。因此我說，數據庫設計與自然語義的沖突，其實就是說關系型數據庫與面向對象語言之間無可調和的矛盾。
換句話說，在面向對象中，屬性不一定是原子的，數據也不一定沒有冗余，因此數據庫的三大范式對于面向對象設計來說，是不適用的，這也就間接導致了，關系型數據庫和面向對象設計時沖突的。
（注：由于本人對 ORM了解甚少，以下言論請大家選擇性相信，也希望大家不吝賜教）其中ORM就是為了解決面向對象與關系型數據庫不匹配而產生的技術。很多人在用ORM時有一個誤區，就是首先建立數據庫，然后由數據庫生成實體對象，但是在我看來，數據庫只應該是存儲數據的工具，而絕不應該成為整個項目設計的核心，正確使用ORM的辦法應該是把程序自動持久化到關系數據庫中，而我們在程序中對數據庫是一無所知的，我們操作的只是一個對象的集合罷了。我不清楚ORM當今的發展，但是在我看來，一個完美的ORM系統應該具備解析對象，然后將對象轉換為符合范式的數據庫結構的能力。
另外，視圖和緩存表也是解決方案之一。
最后，我們只能期待對象型數據庫的進一步成熟了。
13. 我眼中的未來語言
在我眼中，語言的發展方向應該是逐步貼近語義，試想從第一代語言發展至今，語言的趨勢無非是越來越適合于程序員使用，提高程序員的工作效率，說句再難聽些的，就是逐步降低系統開發程序員的門檻，其體現一者在于方法封裝的逐步完善，二就在于越來越接近自然語言，越來越接近“大型作文”的寫作過程。
那么當軟件發展到一定程度，我認為未來的語言是等同于自然語言的程序設計語言。從而人人可編程，方法高度封裝，編譯器可識別人們的自然語言語義從而轉換成機器可識別的語言。我們需要做的只是把需求整理成“無語病”的需求分析文檔，然后把文檔移交給“編譯器”，返回給我們的是一個個.exe，.ASPx。
也許到了那一天，程序員這個職業不復存在了，取而代之的是作家，這一天，我們說，軟件真的發展到了最高階段。
it知識庫：基于自然語言的軟件工程和程序設計（下），轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
