接著上一篇文章繼續(xù)往下講。如果按照上一篇文章走下去的話，現(xiàn)在估計做了有些小軟件了吧。字符串和圖形都容易做大，而且對于潛意識上喜歡數(shù)學(xué)的最有希望的程序員們也是有吸引力的。但是這兩種東西卻不容易做好。等到程序到了一定規(guī)模的時候，維護和效率這兩大問題就會凸顯出來。心急吃不了熱豆腐，為了解決維護和效率這兩個經(jīng)常會出現(xiàn)的問題，我們需要學(xué)習(xí)算法和架構(gòu)。這兩種東西是可以同時學(xué)的，但是一篇文章說不了多少東西，那么就從算法開始吧。

    程序員是需要開闊眼界的，光C#一門也是不行的，畢竟程序運行在各種平臺上，有各種各樣的語言。譬如Win32上的native C/C++、Delphi等，.NET上的C#和VB.NET，還有自成體系的Java，然后就是運行在mainframe上的COBOL，剩下的還有各種各樣的函數(shù)式語言、腳本語言等等。熟悉了C#的人從Delphi入手不會很困難，從C/C++入手也可以了。這兩門原本是本地語言的語言在編寫程序的時候需要我們注意多一些的東西，典型的就是內(nèi)存管理。這還是需要多加練習(xí)的，在這里就不多說了。

    說到算法，在這里首先向大家推薦《算法導(dǎo)論》第二版。一年前我去買的時候，發(fā)現(xiàn)了中文版，但是中文版那個時候仍然有一些章節(jié)沒有翻譯。不知道現(xiàn)在怎么樣了。英語好的同志們可以去買英文版。

    算法與數(shù)據(jù)結(jié)構(gòu)是經(jīng)常出現(xiàn)在一起的。每一種算法總會有在各種不同數(shù)據(jù)結(jié)構(gòu)上的實現(xiàn)，用于處理不同的問題。在不同的語言上面，各種各樣針對實際問題的數(shù)據(jù)結(jié)構(gòu)也有一些巧妙的做法和通用的做法。我們可以用STL，可以用System.Collections.Generic，也可以自己寫。這根據(jù)實際情況而定。我們并不是不能做的比STL好，只是STL已經(jīng)相當(dāng)好了，滿足了大多數(shù)人的需要。在特定的情況下，面對非常特殊的問題，有時候我們就要自己實現(xiàn)數(shù)據(jù)結(jié)構(gòu)。使用上一篇文章說的辦法來聯(lián)系的話，到了這個時候已經(jīng)寫了不少代碼了，用了不少并不復(fù)雜的數(shù)學(xué)知識了，鍛煉了理論與實際相聯(lián)系的基礎(chǔ)。有了這些基礎(chǔ)，我們學(xué)習(xí)算法和數(shù)據(jù)結(jié)構(gòu)會比較簡單。

    常用的數(shù)據(jù)結(jié)構(gòu)有鏈表、列表、堆棧、隊列、二叉樹、平衡樹、堆、哈希表和圖等，除此之外還有各種各樣的變形，但是萬變不離其宗。圍繞著這些數(shù)據(jù)結(jié)構(gòu)還有各種各樣的算法。典型的有排序算法、搜索算法、尋路算法、網(wǎng)絡(luò)流等等。還有一些屬于策略的算法，譬如貪心算法、動態(tài)規(guī)劃等等。屬于策略的算法經(jīng)常用于制造新的算法，要慢慢體會，勤加思考才行。至于這些數(shù)據(jù)結(jié)構(gòu)和算法的實際內(nèi)容我并不打算在這篇文章講。《算法導(dǎo)論》用了半本書來說這些問題，還是看書的好，文章不夠詳細(xì)。

    至于我們?nèi)绾芜x擇算法呢？就如同我剛才強調(diào)的一樣，我們需要聯(lián)系理論與實際的經(jīng)驗，我們要用數(shù)學(xué)的眼光來看待我們需要解決的問題。如果我們找到了一種簡潔的表示來描述我們的問題的話，我們同時也找到了解決問題需要的數(shù)據(jù)結(jié)構(gòu)的雛形。當(dāng)然這個數(shù)學(xué)并不是指數(shù)學(xué)分析這些，我覺得更接近于抽象代數(shù)。扯遠(yuǎn)了啊，一般來說我們并不需要鉆研這些學(xué)科，我們只需要有感覺就好了。培養(yǎng)感覺的一個捷徑就是學(xué)習(xí)數(shù)學(xué)。當(dāng)然不學(xué)習(xí)也可以，經(jīng)驗也能知道我們做事情，只不過走的路要長一些。至于讀者希不希望學(xué)習(xí)數(shù)學(xué)就自己決定吧，沒有普適的道路。找到了數(shù)據(jù)結(jié)構(gòu)的雛形之后，剩下的就是尋找算法了。有一些算法可以在書里面找到（譬如ACM很喜歡考的題目），有一些算法可以在論文中找到（譬如專門為了對付一些復(fù)雜問題而制造出來的不具有通用性的算法），剩下的就要靠我們自己去推導(dǎo)了。

    那么，我們?nèi)绾螌W(xué)習(xí)算法呢？我們是為了解決實際問題才學(xué)習(xí)算法的，是為了為將來自己遇到問題的時候有個指導(dǎo)方向才學(xué)習(xí)算法的，我們并不是為了學(xué)習(xí)算法而學(xué)習(xí)算法。我見過兩種不同的學(xué)習(xí)算法的人。第一種是直覺閱讀算法并學(xué)習(xí)，以后碰到問題再尋找。另一種則是僅僅將算法稍微了解一下然后就放開，以后遇到問題的時候再翻開相應(yīng)的算法來學(xué)習(xí)。兩種方法適應(yīng)于兩種不同的人，并沒有什么大的優(yōu)劣之分。于是我們根據(jù)自己的興趣或者需要，終于必須掌握一種算法了。那么這個時候我們可以找資料來看，就跟閱讀文章一樣消化里面的知識，然后就寫一些小程序來試驗試驗（或者叫做原型，那些做軟件工程的人都喜歡這么說）。這種小程序?qū)儆趻仐壭驮停瑢懲昙慈拥模康氖菫榱俗屪约涸诹私饬怂惴ǖ膬?nèi)容之后，檢驗一下自己是否已經(jīng)真的明白了執(zhí)行這個算法所需要的所有細(xì)節(jié)問題。等到覺得自己已經(jīng)能控制這個算法的時候，我想也就差不多了吧。

    有些人可能會覺得算法很復(fù)雜，因為書里面的算法都是非常復(fù)雜的。但是算法的目的是為了快，因此有一些好的算法跟數(shù)據(jù)結(jié)構(gòu)，結(jié)合的時候可能會變得相當(dāng)簡單，但是并不是很容易想到。在這里我舉幾個簡單的例子。

    喜歡做圖形的朋友們，大概都喜歡做游戲吧，嘿嘿。我們小時候在做那種簡單的2D游戲的時候，總是要計算一大堆人之間是否相互接觸，或者很多人放出的魔法是否跟敵人碰撞到。如果我們的地圖上有100個人，每個人放了兩招，兩兩檢驗是否碰撞（以便判斷是否應(yīng)該實施攻擊）的話就需要檢查20000次。這顯然是不行的。那么我們可以使用分而治之的原理來做。我們可以把地圖切成很多個區(qū)域，區(qū)域包含著人和魔法。每當(dāng)人和魔法的移動越過區(qū)域的邊界的時候，人和魔法就把自己從前一個區(qū)域斷開，鏈接到新的區(qū)域里面去。這個時候區(qū)域就保存了兩個鏈表，一個是人，另一個是魔法。好了，如何檢查魔法和人互相碰撞呢？只需要檢查同一個區(qū)域里面的就行了。如果這100人都在25個區(qū)域里面，平均每個區(qū)域有4個人8個魔法，那么兩兩檢驗的話只需要檢查4×8×25=800次，相對于前面的暴力算法節(jié)省了96%的時間。當(dāng)然這只是理想狀態(tài)。

    在這里舉另一個例子。我們都覺得C#、VB和Java很神奇吧，東西new了都不用delete，多舒服。假設(shè)我們現(xiàn)在要實現(xiàn)這種功能的話，我們需要維護所有已經(jīng)new了的內(nèi)存空間，并執(zhí)行一種搜索算法來判斷哪一些內(nèi)存空間是再也不可能被訪問的然后標(biāo)記，最后刪掉所有被標(biāo)記的空間。于是我們需要一個內(nèi)存管理器，用來申請、標(biāo)記和釋放。如何做比較合適呢？

    我們的內(nèi)存管理器需要根據(jù)設(shè)置的長度返回一段句柄來代表內(nèi)存空間，然后需要可以通過句柄來訪問內(nèi)存，最后標(biāo)記并一起刪除這些句柄。為什么要句柄呢？因為如果直接返回指針的話，語言執(zhí)行久了會產(chǎn)生很多內(nèi)存碎片，而且new和delete也不夠快。現(xiàn)在，我們需要以下幾個數(shù)據(jù)結(jié)構(gòu)：

    ·一個記錄所有被new了而且delete過的句柄的列表，用于迅速獲得沒有正在被使用的句柄。
    ·一個記錄了所有正在使用的句柄的列表，記錄指針以及長度。這張表是一個數(shù)組，句柄是索引。

    new的時候，我們查詢第一張表拿出一個空閑的句柄。如果列表為空的話那么將第二個表變大（這個時候所有句柄都被使用）并且將第一個空閑的（也就是原來的表接下去的第一個新空間）句柄所對應(yīng)的記錄標(biāo)記使用。然后我們分配的總是最末尾的地方
    delete的時候，我們查詢所有標(biāo)記了使用句柄，看看是否有被mark，有的話就標(biāo)記為不使用并將句柄放置入第一張表。
    mark的時候，我們查詢這個句柄所對應(yīng)的記錄，然后mark。
    collect的時候，這是一個操作，將所有內(nèi)存碎片清除。我們只需要順序遍歷第二章表，將有用的內(nèi)容挪動到前面一大塊無用的空間里面，復(fù)制一下數(shù)據(jù)然后修改一下起始指針即可。

    圖示一下：
    空閑句柄：1 2
    句柄記錄：<0,0..9><1,NULL><2,NULL><3,40..43>
    內(nèi)存空間：[第0-9個字節(jié)占用][10-39不占用][40-43被占用][此處為末尾]

    好了，我們需要申請一個內(nèi)存空間，我們拿到了句柄4，需要10個字節(jié)。
    空閑句柄：1 2
    句柄記錄：<0,0..9><1,NULL><2,NULL><3,40..43><4,44..53>
    內(nèi)存空間：[第0-9個字節(jié)占用][10-39不占用][40-43被占用][44-53被占用][此處為末尾]

    現(xiàn)在我們標(biāo)記3并刪除：
    空閑句柄：1 2 3
    句柄記錄：<0,0..9><1,NULL><2,NULL><3,NULL><4,10..19>
    內(nèi)存空間：[第0-9個字節(jié)占用][10-19占用，從句柄4挪過來的][此處為末尾]

    分析一下時間復(fù)雜度吧，這里分析的是絕大部分情況，根據(jù)數(shù)據(jù)結(jié)構(gòu)的實際實現(xiàn)偶爾會有少許偏差。
    new為O(1)，因為從空閑句柄獲得內(nèi)容為O(1)，分配末尾內(nèi)存為O(1)，找到記錄并標(biāo)記為O(1)
    mark為O(1)，因為找到記錄并標(biāo)記為O(1)
    delete為O(1)，因為只需要標(biāo)記
    collect為O(n)，因為遍歷句柄記錄O(n)，挪動內(nèi)容，就算最多也就挪動整段內(nèi)存空間，也是O(n)
    從句并獲得內(nèi)存地址也是O(1)

    我們僅僅需要在內(nèi)存不夠的情況下才動用win32的api分配一塊新的大內(nèi)存，這樣來看的話在大部分情況下我們的內(nèi)存管理器的分配比操作系統(tǒng)做得還快，這也是為什么C#作為托管語言并沒有明顯慢下來的一個原因。當(dāng)然還有一些其他原因，譬如.NET虛擬機會把一些托管代碼臨時編譯成本地代碼等等。

    至于第三個例子，就看這里吧，為了做一個大作業(yè)而弄出來的利用動態(tài)規(guī)劃是顯得簡單尋路算法。

    說到這里本篇也快結(jié)束了。舉著兩個例子只為了說明以下問題：
    ·算法往往跟執(zhí)行效率有很大關(guān)系
    ·好的數(shù)據(jù)結(jié)構(gòu)才能發(fā)揮算法應(yīng)有的威力
    ·要根據(jù)實際情況來選擇，甚至自己思考算法
    ·算法并不都是復(fù)雜的

    其實，對于數(shù)據(jù)結(jié)構(gòu)和算法不熟悉或者根本沒聽說過的話，也并不是就不能寫出一些稍微有點規(guī)模的程序，只是寫出來的程序可能會很亂。算法在一個程序員的發(fā)展道路上看還是最好學(xué)一學(xué)。