說文解字
《說文解字》，簡稱《說文》，是由東漢經學家、文字學家許慎編著的語文工具書著作。《說文解字》是中國最早的系統分析漢字字形和考究字源的語文辭書，也是世界上很早的字典之一。
以上是“說文解字”在百度百科的解釋，前段時間刷知乎時，看到了Ｗ雨辰一篇介紹漢字造字法（指事，象形，形聲，會意，轉注，假借）的文章，其介紹簡單有趣，深入淺出，讀完了之后感覺漢字的造字與程序設計、尤其是面向對象的設計有許多共同之處，寫一篇文章記錄一下思路，感興趣的朋友可以一起來探討下。
說文解字的格式
說文解字是有固定一種格式的，網上有許多網站支持搜索《說文解字》，打開一個詞典網，在上面搜索“老”字，彈出來的結果是這樣的：
這個格式分三部分：
1. 元數據：某字，配一張圖。
2. 職責：Ｘ也。
3. 實現：從ＸＸ
比如：
化：教行也。從匕從人，匕亦聲。
型：鑄器之法也。從土刑聲。
改：更也。從攴己。
它的模型猜想圖如下：
解字
庖丁解牛，解一個漢字，看看說文解字是如何詮釋的：
改：更也。從攴己。
這個【改】字的解釋有點意思：從，就是繼承的意思；從攴，繼承於攴，攴從圖畫上看是一根小樹枝的意思。那么這個“攴己”，就是揮舞着小樹枝抽打自己……Why？為毛要抽自己？因為自己欠抽嗎？？
——因為［更也］。更，更新，鞭策自己是為了改過自新。
換成面向對象的語言：
class 更 {} class 攴 { public 更 Do(object o); } class 改 : 攴 {} var o = new 改(); var result = o.Do(new 己())
從攴，從有繼承的意思。從支己，就是繼承（攴）並調用函數傳參（己）的意思。
這里有歧義的地方是“更也”，這個“更”不能僅僅做返回值處理，其更多的是表達了一種差量元數據（diff merge's metadata），這個差量元數據體現出了目的性：
——鞭策自己是為了更新，這是“改”的本義。
用程序設計的思路描述：
class B {} class C {} class A ：B { public C do() }
翻譯成說文解字：
A，C也，從B。
又如：
class B {} class C {} class D {} class A ：B { public C do() { this.RaiseEvent(new D()); } }
翻譯成說文解字：
A，C也，從B，D聲。
順着這個解釋，說文解字有着一系列精彩的發揮：
比如前面提到的“老”字：從人毛匕，它有三個元素：從人、毛、匕（hua=化）。
按照知乎上w雨辰的解釋：“人、毛、化”就是人的毛的化的意思——將人的毛看做頭發，頭發變化了……大概率是變白了……變白了就是老了。
這樣就通過人——毛——匕的鏈條將“老”的意思解釋清楚，這個令讀者使用“意會”的方式get到字的方法，按照許老的說法：叫做《說文解字》。
這個人—毛—匕的解釋，在面向對象的語言中非常常見，就是對象的屬性賦值：
class 人 { public object 毛 { get; set; } } var ren = new 人(); ren.毛 = 匕；
以程序的角度來看，毛是人的一個屬性，匕是毛的當前狀態值。相當於
{人，毛，匕} => 老
漢字造字的原理有點意思，它將【動態】的屬性賦值（或者叫方法調用），連帶着參數壓縮成了一個【靜態】的字，化動為靜，在讀者閱讀時再通過意會的方式在讀者腦子中解釋執行。這種模式有點類似於反射，但類型信息又非常靈活。
這種把多級的信息集壓縮到一個平面上，使其變成一個字，是漢字的一個造字原理。其展開方式來自於讀者的意會：造字時將立體壓縮成平面，理解時在讀者腦子中將平面還原成立體。
象形，指事，形聲，會意，轉注，假借
談到了設計少不了模式，類似於程序設計的原則（開閉原則、單一職責原則等），說文解字也總結了其六大模式（設計原則），分別是：象形，指事，形聲，會意，轉注，假借，統稱為六書：
六書：
一曰指事。指事者，視而可識，察而見意。上下是也。
二曰象形。象形者，畫成其物，隨體詰詘，日月是也。
三日形聲。形聲者，以事為名，取譬相成，江河是也。
四日會意。會意者，比類合誼，以見指撝，武信是也。
五日轉注。轉注者，建類一首，同意相受，考老是也。
六日假借。假借者，本無其字，依聲托事，令長是也。
尋找下對應關系：
一、象形：顧名思義，就是抽象，通過形狀上的相似抽象出對象。
object o = new object();
二、指事：指事。這個事用來特指，好比電影里面的特寫鏡頭，點出來說明些“特殊味道”。
比如說 本 = 木 + 一，下面的“一”代表了樹木的根部，用一（橫）指出來，提醒人不管長多大，都不要忘記最初的一橫。
指事在面向對象語言里，多用事件或消息表述：
o.RaiseEvent()；
三、形聲：把兩個或多個對象放在一起來衍生，
“形”：定義了邊界，定義了輪廓——對象在環境中的外在。
“聲”，類似波，指對象對外能發出的功能。
Class A； Class B { A a; public void Do { a.do()} }
按照漢字的解釋，一個對象調用另一個對象的方法，就是借助此一對象讓另一對象發出“聲音”。
漢字在這里的解釋有些意思，聲音無孔不入，對一個對象的方法調用，表面上看，似乎只會對被修改的對象產生影響。而漢字用聲音說明，這種改變對象狀態會對系統內的所有對象產生影響，只是不容易從表面看出，因為光還沒有照到其它對象。
好比，一個人聽了一句話，雖然表面上不動聲色，可內心早已mmp的……波瀾洶涌。
四、會意：使用多重繼承，將兩個意象並列放在一起，令人意會。
比如“信”是會意，把“人”和“言”放在一起，令人意會（……人和言放在一起是什么意思……信的意思嗎？），意會出的意思就比較接近了。
Class A；
Class B；
Class C：A,B
相比於程序設計極力避開多繼承，避開菱形繼承，漢字系統就是建立在多繼承的基礎之上，在程序設計中is-a是主體，has-a是優選；而漢字系統中has-a是主體，is-a是優選。
五、轉注：類似多態，又有點像函數調用鏈。
老，從人毛匕——“人”，調用“毛”，再調用“匕”，這種調用更像是一種連接，如何把“人”、“毛”、“匕”用合理性的方式連接起來，直接傳達出使用者的意圖。
令功能本義不變，邊界旋轉，尋找一種可以從一個字注入到下一個字的方法。
class A { private B b; public void Do() [ b.Do(); } } class B { private C c; public void Do() [ c.Do(); } }
六、假借：
按照wu雨辰的解釋：
比如“美”是指味道鮮美，但是人長得漂亮怎么形容呢？比如把人和美放在一起，那就把美假借為了“美麗”的意思了，跟“美”的本義“美味”意思不同，但是有沒有必要再為了這層意思再造一個字形呢？其實沒必要的，把“美”的字形拿過來假借一下，大家自然就明白什么意思了，“美”每變一個情景，就多一種假借，而且這個假借還讓你看起來不動聲色，后來才有了一字多義。
假借有種類型推斷（匿名類型）的味道，將字還原到本義（將class還原成data、甚至還原成元數據metadata），再將其適配到其他字（類型）。
假借有一種系統間通過DTO傳參的味道：
struct Data {} class A { public Data ToDTO(); } class B { public static B FromDTO(Data data); } A a = new A(); var data = a.ToDTO(); var b = B.FromDTO(data);
模型
回到最初的字模型，猜想一下：字=元數據（形）+職責（音）+實現（義）
其模型圖：
漢字是一種象形文字，它和拼音文字相比，最大程序保留了元數據（圖）。
有了元數據，系統就有了回溯的可能——當漢字無法理解（無法溝通）之時，可以還原到圖上來理解，相比於拼音文字，它提供了一種回溯（Recompile）的可能性。
使用者隨時可以利用元數據瓦解一個字，來獲得其原始“意圖”。類似於對象設計中的object.GetType()，隨時可獲取對象的類型數據，這個元數據是以一種更高級別的抽象（粗略的圖）來提供的。使用者可以與時俱進，將元數據的圖根據當前環境重編譯（重解釋），以更好的適應時代的變化。
漢字的系統演進了幾千年（或更久），現代的編程語言幾年內就會有種面目全非、令創始人都感慨的變化，而漢字系統依舊保持着旺盛的生命力，其形音義的設計理念有着精髓之處，值得令人深挖。
這種在編碼的時候附帶元信息的方式，在程序中可是特性、或是注釋，在溝通里被稱為意圖，在設計上又看成背景。通常情況下，它與主信息之間呈現一種分離態。
而在漢字系統中，形音義“三位一體”，一個字的形音義必須全部確定后，它才會長久地存在下去。
漢字演進
乘坐時光，回到漢字的早期年代，觀察一下漢字的演進：
舉個例子： 需求。
需求由“需”和“求”兩個字組成。
需字：
求字
這兩個字的圖片有點意思，一個是一位"濕身"的男子，一個是一只伸長了求索的手。
需：天在下雨，人被淋濕。
求：一只伸長的手。
當“需”和“求”兩個字金風玉露一相逢，便交會了人間無數。
做軟件的少不了“需求”，這是一個高頻詞語，帶點文縐縐，又很壓人……“這個需求能否解決？”“確認一下客戶需求。”“這個需求不合理。”
從元數據（圖）上來看，這個詞會有哪些啟示呢？
單從圖上來看，需求出現了三個基本元素：雨、人、手。
缺少這三個元素的其中之一，都不能稱之為“需求”，比如：
1. 如果天不下雨，那就不叫需求。
2. 如果人沒被淋濕，也不叫需求。
3. 如果沒伸出手，更不叫需求。
換成客戶（爸爸）的解釋：
1. 如果市場環境沒發生變化，不叫需求，提了白提，客戶不理解——（雨）。
2. 如果客戶沒傷到切身利益，不叫需求，說了白說，客戶不痛——（人）。
3. 如果客戶沒主動要求，不叫需求，皇帝不急太監急，沒用——（手）。
將這個解釋抽象出道理：
1. 如果大環境、時間不對，不叫需求——天時。
2. 如果區域不對，不叫需求——地利。
3. 如果客戶吃瓜看熱鬧，不叫需求——人和。
這是一種越過詞語，直接從元數據（字義）看圖說話的解釋，相對於詞義，漢字的字義往往攜帶了更精髓的最初的元信息。
再舉個例子：封裝（面向對象高頻詞）。
封=圭+寸（圭，諸侯的玉圭，代表責任；寸，恭恭敬敬手持，代表守責任）
裝=衣+壯（衣，上身穿的叫衣，下身穿的叫裳；壯，大也）
從字面來說，封裝：要有責任，守責任，上身穿的好，肩膀端得住。
這個字面分析給出了一個很有意思的觀點：面向對象的封裝只封“上半身”即可，要玩“下半身失蹤”。也就是說，面向對象的封裝要有一種“並蒂蓮”，要保留通過地下（類似於指針、內存）等從下一層次訪問修改的可能性。
另，“壯”說明，對象的聚合性永遠呈放大趨勢，其有像龍卷風一樣將其它對象席卷其中的野心——每一個對象都有成為“聚合根”的沖動和向往。
漢字系統
漢字的系統設計非常靈活，一個字既可以充當另一個字的基類，又可以充當另一個的方法、甚至可以是另一個字的元數據，其合理性來自於群體認證：
一個字（對象）不是合理才能應用，而是因為應用才產生合理。
漢字的意會方式是一種元數據交流方式，意會的過程是一個先編譯后執行的過程。如果把兩個人比做兩台電腦，在它們的網絡通信中，不使用RPC調用，不使用Restful方法，而是在傳輸中直接傳送元數據，接收方得到元數據，在其本地進行（無厘頭）編譯，以一種本地熱重載（創建類型、JIT編譯、解釋執行）的方式完成溝通。
意會是一種“大數據”編譯。
這種元數據通信方式可以充分的解耦，其有很高的擴展性，其本地編譯的效果取決於“常識”、“經驗”、“情感”，像是一種“大數據”編譯，其注重的是不要喪失“不確定性”，不確定性是確定性的背景，它為確定性提供了生命力以及演化的可能性，它使得概念向本義收斂與邊界擴張兩個維度變化。
總結
本文討論了《說文解字》與程序設計的關系，但牽強附會的地方很多，很多地方都是（無厘頭）編譯——開局一張圖，內容全靠編。
偉大系統總有共通之處。
作為流傳了幾千年、上萬年的文字系統，其內部有很深的智慧存在。
學習先賢，吸取一些經歷時間（實踐）證明過的設計真諦，希望程序設計和漢字設計能夠借鑒、融合。
希望有風來的地方，都有陽光閃耀。
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。