讀貼有感。演算法、資料結構和OO、設計模式,初學者的你還在懷疑嗎?
其實我也是跟banq一條路的人,我開始弄演算法,資料結構這些東西,在做軟體發現一個軟體不是什麼迴圈、什麼動規所能解決的問題,我自己不斷地寫子函式,不斷的複用,原來自己正走向OO了,現在的軟體設計不是一兩個演算法和資料結構所能解決的問題,其實是軟體的複雜化做成的,雖全用演算法實現可以,但那樣是高代價的。當我不斷地懷疑的時候,於是我找到了OO,接觸了框架,然後遇上了設計模式。曾經因為OO而藐視演算法,但不斷的認識和經歷使我知道兩者雖然是對立的,但也必須並存。
一個不知恰不恰當的比喻:
城市規劃,不需研究汽車排氣來減少汙染,只需知道越少越好,當有更少排放的車輛,就換進來。(不選用低排放汽車,城市汙染)
軟體設計,不需研究演算法速度來加快響應,只需知道越快越好,當有更快速度的演算法,就換進來。(不選用高速度演算法,軟體緩慢)
閱讀帖子http://www.jdon.com/jivejdon/thread/31338後有感而發,我也是過來人,是一個從演算法轉過來的人,對於懷疑和迷惑也深有感觸,於是對帖子中一些問題進行了討論和回答,希望對迷惑和初學的人有所幫助:
1、之前有人說出一個什麼公交問題,要我們用設計思想實現,我笑了,我看見下面的答覆,更笑了(為啥總是要向著過程想呢,我第一件事想到的策略模式,這大概就是設計模式的思想不同之處吧,關於演算法的反應第一個幾乎就是策略):
banq說的是OO是根本不需要經過BS1是“如何實現”的基礎,也就是演算法,對於OO來說上面這樣就寫完了,至於演算法那部分,隨便找個懂演算法的人來實現他就行,演算法效率不行也是演算法的人的事,與我們OO設計沒關,BS1演算法不行就找個行的BS2換了就行,上面程式碼跟演算法就一點關係——複製與粘帖,對不懂演算法的人來說一樣可以OO,一樣可以實現軟體。
當然也可以去探討演算法,但這樣的做法就走向底層了,與OO是截然不同的路線,我們很多人都從JAVA\C和C\C++開始,這面臨選擇走向的問題,向上走向下走,為什麼banq說是兩條相剋的路線就是這樣的道理了(你同時走兩條路,也不能說這是一條路)。(黑箱子和白箱子是兩個心態,改變了就好了,當然不少人可以自由轉換,但對於初學者還是不要為好,容易走歪路)
2、還有人說到JAVA程式碼和API實現,我只能告訴你那只是實現方式,我完全可以換一種,JAVA只是一門語言而已,是用來表達意思的,就像中文一樣(API就行中文的語法規則一樣),我記得一句話:OO的偉大在於它可以替換(其實就是抽象思想)。banq之前所說的XML實現資料庫也是一個道理。注:別把JAVA和設計模式等同起來,我們只不過是用JAVA來表達設計模式而已。
那個Collection問題,Collection是具體實現而已,對於OO設計來說,我完全可以不知道里面在用什麼數學結構,或者說完全不知道里面是幹什麼,我只需知道我給它什麼,它就能給我什麼(黑箱子),其實和策略模式道理差不多。
3、
>>對底層資料庫,作業系統的研究是浪費精力和時間,但也不能說是能力不足的體現啊,我看能把作業系統研究通的程式設計師是最偉大的,最可敬的.不研究怎麼能用活那,怎麼能借鑑別人的技術來開發自己的啊!一大批人是不需要對這進行研究(包括我),可中科院和一些研究所的搞科研的人需要研究啊,不研究中國怎麼在計算機界有質的飛躍啊!
<<看到這一句我首先笑了,我想問的是:你是在問OO還是問中國計算機發展呢?banq說的是若果你要走OO這條路(軟體解決方案),就不要去看底層的東西(因為很多人都因為學了C後都很難轉過頭來,感覺很彆扭),即使學了也要儘可能快的跳出來(我們學底層是借鑑思想,不是單單去看具體實現,當然我們要從具體實現得出思想),跳不出來就別走OO這條路。
4、
>>UML建模是很強,建再多的類,實現再多的物件,物件裡面總要用到資料型別,演算法,只不過類和物件組織的程式比以前的只用函式實現功能的程式導向的程式要好的多的多的.一個簡單的鏈和陣列也算是資料結構裡面的吧!一個簡單的for語句,遞迴語句也算是簡單的演算法吧!banq老師說的資料結構和演算法就是符號,不懂演算法和資料結構,用UML把類圖完美的畫好,可怎麼實現啊(因為人都學模式設計,框架去了,沒人懂演算法和資料結構了,連程式和執行緒也不懂了,就知道一切都可以用物件實現,可怎麼實現啊?
<<我們怎麼實現也是對設計模式(或者說方案更加準確)的實現,不是對針對演算法的實現,這裡衍生出一個觀點就是——方案解決專案,技術解決問題。雖然這兩項並不是排斥的,但方案裡面最多就包含“選擇”什麼技術,但不會去想怎樣去實現技術。初學者可能就是想不通這點:包含技術為什麼可以不深入認識?其實就是“選擇”技術而已。要是用黑箱子也要知道里面的怎麼工作的話,黑箱子還有用嗎?鏈和陣列也是同樣道理。
5、
>>深入技術內部就是向下思維,向上思維和向下思維有這樣說的嗎?就象windows一樣,大家只管用它,不需要管它怎麼實現,對大部人來說真是這樣(包括我),為什麼好多公司,好多研究人員千方百計的想讓蓋茨公開原始碼啊!要是windows真公開了,肯定他們會好好的研究一下,爭取在windows的基礎上做出比它更好的系統,難到這些公司和研究人員也是向下思維嗎?
<<這只是大眾定義而已,向下並不是說向低階的意思,只是我們縱列地劃分幾個層然後說向上向下而已,就像說相容的說法一樣,你反過來說也可以,不過就不能和大眾溝通了。那些公司和研究人員也是向下思維,因為系統不像應用軟體,系統需要底層支援,它和硬體是密切相關的。但系統沒有邏輯業務,因為它只是應用軟體的載體。搞系統和搞應用軟體不一樣。
6、
>>哲學中有這樣幾句話:"事物之間都是相互聯絡的","一切事物都在變化之中",怎麼能說OO是和這些傳統基礎知識是水火不容的啊!
<<看到這句話,我首先問一句:“矛盾不是聯絡嗎?”
7、
>>只是java幫你封裝了,你覺得也夠用了
>>如果真的有一天你需要自己來處理記憶體中的資料
>>建立自己的hash函式,這就很重要了。
>>
>>框架永遠脫離不了演算法與資料結構的
<<我只能說你現在不是在做應用軟體了,你是為做應用軟體提供條件,OO和設計模式這些只是思想,跟具體API沒有關係,有人幫你實現能用的API就行,沒有就自己設計API(這是就是一種向下妥協的做法,沒有好與不好,只是沒有條件而必須要做而已,一點也證明不了“OO等思想需要底層技術支援”),但這跟OO和設計模式的存在地位沒有任何改變。
8、
>>如果你打算當藍領工人,那麼請努力學習那些framework,因為你的公司需要它們,需要他們來做專案。但是如果真的想發展,走入軟體的核心,進入ibm,microsoft,google,去進入到核心,請仍然回到演算法與數結構上。
<<系統有系統的架構師,應用系統有應用系統的架構師,誰說不一樣了,別以為一知半解就可以妄下定論。學現成的框架是為了降低成本和快速開發而已,一個系統建立一個基礎架構,這個成本你花得起?。架構師跟coder不一樣,架構師是腦力活,coder才是體力活,只要在計算機領域都有他們的存在。即使是windows也有架構,只不過是一個不為認知的架構罷了。
9、
>>他現在有兩種選擇,一種是學習struct,學習hib,學習spring,可能三個月,他不明白為什麼,但是他能作專案了,可是他被繫結在>>java,struct,hib上了,因為下一個專案的時候老闆會覺得他已經熟練使用這些了,下次你還要用這個。如果跳槽的時候他的簡歷也>>一定是熟練掌握XXXX,我想現在中國大多數的程式設計師的生存狀態就是這個樣子的。
>>
>>另外一種方式你,學習資料結構,學習演算法,可能需要一年的時間,你可能做不出任何像樣的東西,但是,當你真的對演算法與資料結>>構真的成竹在胸的時候,你可以去ibm,micorsoft,google這些公司去,他們真的能拒絕這樣的高手麼??
<<這就是banq所說中國的病態教育造成的,明顯是缺乏了思考,那些架構都是大部分包含設計模式的,那個架構師不懂設計模式,那我真懷疑他水平?(當然我永遠不會只說23種的,因為時代在進步的,但肯定少不了設計思考)這也出現了一個現狀:中國得到國際認可的框架如牛毛一般。(現在我只知道1)
<<設計模式是獨立於語言以外的,是一種思想,是要靠抽象思考的,我很幸運大學裡有一門“物件導向分析與設計”的冷門選修,而且新開的,至少我感到這個病態應該開始醫治了。
10、
>>struct能活多少年,你知道麼??spring能流行多長時間你知道麼??三年前J2EE被吹上天,現在又被貶的一敗圖地,那麼你是不是感到彷徨與徘徊??現在流行ajax你學一下,明天流行spring你學一下,人的精力有多少??
<<因為“只用不想”的人,是跟不上潮流的,因為思想是長期的,應用是短暫的。若果只跟隨具體struts和spring這些具體的東西,遲早會被潮流打敗。struts、spring這些東西看起來學一樣已經夠累了,但從過去到現在的例子中,只有思想是穩定,他們都包含設計模式的思想,懂了這些思想,學一個新的架構,何來難呢?精通後還乾脆加入幾個包,就自己架起架構了(其實大多框架就是幾個包加配置檔案)。學其精吧。
11、
>>總不能一開始就從模式和框架學程式設計吧!
<<就是可以,不過最好有學一門語言來表達那樣就更具有表現力。就像“三次握手”,這是一個思想,難道這一定要和JAVA拉上關係?要和電子硬體拉上關係?在設計模式中的表達完全可以用不同的語言去表達,那就表明他跟語言完全沒關係。學一種語言只是為了表達而已。
---------------------------以下個人想法------------------------
其實我看了那些帖子後也深有感觸,是企業導致教育扭曲,還是教育把企業推錯了方向,還在納悶的是招JAVA程式設計師,考驗的是快速排序演算法。若果是智力考察就算了,但居然是技術考察···是我想錯了,還是他們做錯了。教育教歪了?還是企業不明確真正的需求呢?可能對於企業,他們覺得做出來用到就行,對於教育,教出來的有企業要就行(猜想,猜想而已)。若果真是這樣,中國軟體行業崛起?何時呢?
1、思想方向已經不一樣了;
2、別把JAVA和設計模式等同起來,我們只不過是用JAVA來表達設計模式而已;
3、單靠底層技術發展速度已經不能滿足需求,以前小軟體還可以,現在以業務主的專案,基本不能過多考慮技術了;
4、實現也是對設計模式(或者說方案更加準確)的實現,不是對針對演算法的實現。方案裡面最多就包含“選擇”什麼技術,但不會去想怎樣去實現技術;
5、系統不像應用軟體,系統需要底層支援,它和硬體是密切相關的。但系統沒有邏輯業務,因為它只是應用軟體的載體。搞系統和搞應用軟體不一樣;
6、矛盾不是聯絡嗎?他們這種矛盾正可以互相補充;
7、OO和設計模式這些只是思想,跟具體API沒有關係;
8、即使是windows也有架構,只不過是一個不為認知的架構罷了;
9、中國的病態教育造成的,明顯是缺乏了思考。設計模式是獨立於語言以外的,是一種思想,是要靠抽象思考的;
10、思想是長期的,應用是短暫的。
11、學一種語言只是為了表達而已。
大概歸納以上的觀點吧。
看那帖子挺多討論的,以前的一個說的十個人信了,現在多點懷疑是好的表現,就是懷疑了才會發現缺點,然後進步了。
歡迎各位來懷疑,來討論。
一個不知恰不恰當的比喻:
城市規劃,不需研究汽車排氣來減少汙染,只需知道越少越好,當有更少排放的車輛,就換進來。(不選用低排放汽車,城市汙染)
軟體設計,不需研究演算法速度來加快響應,只需知道越快越好,當有更快速度的演算法,就換進來。(不選用高速度演算法,軟體緩慢)
閱讀帖子http://www.jdon.com/jivejdon/thread/31338後有感而發,我也是過來人,是一個從演算法轉過來的人,對於懷疑和迷惑也深有感觸,於是對帖子中一些問題進行了討論和回答,希望對迷惑和初學的人有所幫助:
1、之前有人說出一個什麼公交問題,要我們用設計思想實現,我笑了,我看見下面的答覆,更笑了(為啥總是要向著過程想呢,我第一件事想到的策略模式,這大概就是設計模式的思想不同之處吧,關於演算法的反應第一個幾乎就是策略):
class BS1 implements BusStrategy{ public int getResult(){ return x; } } class Result{ private bs; public Result(BusStrategy bs){//用IOC更是舒服 this.bs = bs } public int getResult(){ return bs.getResult(); } } int result = (new Result(new BS1())).getResult(); <p class="indent"> |
banq說的是OO是根本不需要經過BS1是“如何實現”的基礎,也就是演算法,對於OO來說上面這樣就寫完了,至於演算法那部分,隨便找個懂演算法的人來實現他就行,演算法效率不行也是演算法的人的事,與我們OO設計沒關,BS1演算法不行就找個行的BS2換了就行,上面程式碼跟演算法就一點關係——複製與粘帖,對不懂演算法的人來說一樣可以OO,一樣可以實現軟體。
當然也可以去探討演算法,但這樣的做法就走向底層了,與OO是截然不同的路線,我們很多人都從JAVA\C和C\C++開始,這面臨選擇走向的問題,向上走向下走,為什麼banq說是兩條相剋的路線就是這樣的道理了(你同時走兩條路,也不能說這是一條路)。(黑箱子和白箱子是兩個心態,改變了就好了,當然不少人可以自由轉換,但對於初學者還是不要為好,容易走歪路)
2、還有人說到JAVA程式碼和API實現,我只能告訴你那只是實現方式,我完全可以換一種,JAVA只是一門語言而已,是用來表達意思的,就像中文一樣(API就行中文的語法規則一樣),我記得一句話:OO的偉大在於它可以替換(其實就是抽象思想)。banq之前所說的XML實現資料庫也是一個道理。注:別把JAVA和設計模式等同起來,我們只不過是用JAVA來表達設計模式而已。
那個Collection問題,Collection是具體實現而已,對於OO設計來說,我完全可以不知道里面在用什麼數學結構,或者說完全不知道里面是幹什麼,我只需知道我給它什麼,它就能給我什麼(黑箱子),其實和策略模式道理差不多。
3、
>>對底層資料庫,作業系統的研究是浪費精力和時間,但也不能說是能力不足的體現啊,我看能把作業系統研究通的程式設計師是最偉大的,最可敬的.不研究怎麼能用活那,怎麼能借鑑別人的技術來開發自己的啊!一大批人是不需要對這進行研究(包括我),可中科院和一些研究所的搞科研的人需要研究啊,不研究中國怎麼在計算機界有質的飛躍啊!
<<看到這一句我首先笑了,我想問的是:你是在問OO還是問中國計算機發展呢?banq說的是若果你要走OO這條路(軟體解決方案),就不要去看底層的東西(因為很多人都因為學了C後都很難轉過頭來,感覺很彆扭),即使學了也要儘可能快的跳出來(我們學底層是借鑑思想,不是單單去看具體實現,當然我們要從具體實現得出思想),跳不出來就別走OO這條路。
4、
>>UML建模是很強,建再多的類,實現再多的物件,物件裡面總要用到資料型別,演算法,只不過類和物件組織的程式比以前的只用函式實現功能的程式導向的程式要好的多的多的.一個簡單的鏈和陣列也算是資料結構裡面的吧!一個簡單的for語句,遞迴語句也算是簡單的演算法吧!banq老師說的資料結構和演算法就是符號,不懂演算法和資料結構,用UML把類圖完美的畫好,可怎麼實現啊(因為人都學模式設計,框架去了,沒人懂演算法和資料結構了,連程式和執行緒也不懂了,就知道一切都可以用物件實現,可怎麼實現啊?
<<我們怎麼實現也是對設計模式(或者說方案更加準確)的實現,不是對針對演算法的實現,這裡衍生出一個觀點就是——方案解決專案,技術解決問題。雖然這兩項並不是排斥的,但方案裡面最多就包含“選擇”什麼技術,但不會去想怎樣去實現技術。初學者可能就是想不通這點:包含技術為什麼可以不深入認識?其實就是“選擇”技術而已。要是用黑箱子也要知道里面的怎麼工作的話,黑箱子還有用嗎?鏈和陣列也是同樣道理。
5、
>>深入技術內部就是向下思維,向上思維和向下思維有這樣說的嗎?就象windows一樣,大家只管用它,不需要管它怎麼實現,對大部人來說真是這樣(包括我),為什麼好多公司,好多研究人員千方百計的想讓蓋茨公開原始碼啊!要是windows真公開了,肯定他們會好好的研究一下,爭取在windows的基礎上做出比它更好的系統,難到這些公司和研究人員也是向下思維嗎?
<<這只是大眾定義而已,向下並不是說向低階的意思,只是我們縱列地劃分幾個層然後說向上向下而已,就像說相容的說法一樣,你反過來說也可以,不過就不能和大眾溝通了。那些公司和研究人員也是向下思維,因為系統不像應用軟體,系統需要底層支援,它和硬體是密切相關的。但系統沒有邏輯業務,因為它只是應用軟體的載體。搞系統和搞應用軟體不一樣。
6、
>>哲學中有這樣幾句話:"事物之間都是相互聯絡的","一切事物都在變化之中",怎麼能說OO是和這些傳統基礎知識是水火不容的啊!
<<看到這句話,我首先問一句:“矛盾不是聯絡嗎?”
7、
>>只是java幫你封裝了,你覺得也夠用了
>>如果真的有一天你需要自己來處理記憶體中的資料
>>建立自己的hash函式,這就很重要了。
>>
>>框架永遠脫離不了演算法與資料結構的
<<我只能說你現在不是在做應用軟體了,你是為做應用軟體提供條件,OO和設計模式這些只是思想,跟具體API沒有關係,有人幫你實現能用的API就行,沒有就自己設計API(這是就是一種向下妥協的做法,沒有好與不好,只是沒有條件而必須要做而已,一點也證明不了“OO等思想需要底層技術支援”),但這跟OO和設計模式的存在地位沒有任何改變。
8、
>>如果你打算當藍領工人,那麼請努力學習那些framework,因為你的公司需要它們,需要他們來做專案。但是如果真的想發展,走入軟體的核心,進入ibm,microsoft,google,去進入到核心,請仍然回到演算法與數結構上。
<<系統有系統的架構師,應用系統有應用系統的架構師,誰說不一樣了,別以為一知半解就可以妄下定論。學現成的框架是為了降低成本和快速開發而已,一個系統建立一個基礎架構,這個成本你花得起?。架構師跟coder不一樣,架構師是腦力活,coder才是體力活,只要在計算機領域都有他們的存在。即使是windows也有架構,只不過是一個不為認知的架構罷了。
9、
>>他現在有兩種選擇,一種是學習struct,學習hib,學習spring,可能三個月,他不明白為什麼,但是他能作專案了,可是他被繫結在>>java,struct,hib上了,因為下一個專案的時候老闆會覺得他已經熟練使用這些了,下次你還要用這個。如果跳槽的時候他的簡歷也>>一定是熟練掌握XXXX,我想現在中國大多數的程式設計師的生存狀態就是這個樣子的。
>>
>>另外一種方式你,學習資料結構,學習演算法,可能需要一年的時間,你可能做不出任何像樣的東西,但是,當你真的對演算法與資料結>>構真的成竹在胸的時候,你可以去ibm,micorsoft,google這些公司去,他們真的能拒絕這樣的高手麼??
<<這就是banq所說中國的病態教育造成的,明顯是缺乏了思考,那些架構都是大部分包含設計模式的,那個架構師不懂設計模式,那我真懷疑他水平?(當然我永遠不會只說23種的,因為時代在進步的,但肯定少不了設計思考)這也出現了一個現狀:中國得到國際認可的框架如牛毛一般。(現在我只知道1)
<<設計模式是獨立於語言以外的,是一種思想,是要靠抽象思考的,我很幸運大學裡有一門“物件導向分析與設計”的冷門選修,而且新開的,至少我感到這個病態應該開始醫治了。
10、
>>struct能活多少年,你知道麼??spring能流行多長時間你知道麼??三年前J2EE被吹上天,現在又被貶的一敗圖地,那麼你是不是感到彷徨與徘徊??現在流行ajax你學一下,明天流行spring你學一下,人的精力有多少??
<<因為“只用不想”的人,是跟不上潮流的,因為思想是長期的,應用是短暫的。若果只跟隨具體struts和spring這些具體的東西,遲早會被潮流打敗。struts、spring這些東西看起來學一樣已經夠累了,但從過去到現在的例子中,只有思想是穩定,他們都包含設計模式的思想,懂了這些思想,學一個新的架構,何來難呢?精通後還乾脆加入幾個包,就自己架起架構了(其實大多框架就是幾個包加配置檔案)。學其精吧。
11、
>>總不能一開始就從模式和框架學程式設計吧!
<<就是可以,不過最好有學一門語言來表達那樣就更具有表現力。就像“三次握手”,這是一個思想,難道這一定要和JAVA拉上關係?要和電子硬體拉上關係?在設計模式中的表達完全可以用不同的語言去表達,那就表明他跟語言完全沒關係。學一種語言只是為了表達而已。
---------------------------以下個人想法------------------------
其實我看了那些帖子後也深有感觸,是企業導致教育扭曲,還是教育把企業推錯了方向,還在納悶的是招JAVA程式設計師,考驗的是快速排序演算法。若果是智力考察就算了,但居然是技術考察···是我想錯了,還是他們做錯了。教育教歪了?還是企業不明確真正的需求呢?可能對於企業,他們覺得做出來用到就行,對於教育,教出來的有企業要就行(猜想,猜想而已)。若果真是這樣,中國軟體行業崛起?何時呢?
1、思想方向已經不一樣了;
2、別把JAVA和設計模式等同起來,我們只不過是用JAVA來表達設計模式而已;
3、單靠底層技術發展速度已經不能滿足需求,以前小軟體還可以,現在以業務主的專案,基本不能過多考慮技術了;
4、實現也是對設計模式(或者說方案更加準確)的實現,不是對針對演算法的實現。方案裡面最多就包含“選擇”什麼技術,但不會去想怎樣去實現技術;
5、系統不像應用軟體,系統需要底層支援,它和硬體是密切相關的。但系統沒有邏輯業務,因為它只是應用軟體的載體。搞系統和搞應用軟體不一樣;
6、矛盾不是聯絡嗎?他們這種矛盾正可以互相補充;
7、OO和設計模式這些只是思想,跟具體API沒有關係;
8、即使是windows也有架構,只不過是一個不為認知的架構罷了;
9、中國的病態教育造成的,明顯是缺乏了思考。設計模式是獨立於語言以外的,是一種思想,是要靠抽象思考的;
10、思想是長期的,應用是短暫的。
11、學一種語言只是為了表達而已。
大概歸納以上的觀點吧。
看那帖子挺多討論的,以前的一個說的十個人信了,現在多點懷疑是好的表現,就是懷疑了才會發現缺點,然後進步了。
歡迎各位來懷疑,來討論。
[該貼被SpeedVan於2010-10-06 17:37修改過]
[該貼被SpeedVan於2010-10-06 17:43修改過]
相關文章
- 自我懷疑的開發者:你夠好嗎?
- 初學者的小疑問
- 學《資料結構》有感資料結構
- 實話設計模式:GOF《設計模式》不適合作為初學者入門讀物設計模式Go
- 還在為你的簡歷苦惱嗎?程式設計師必讀!程式設計師
- 讀資料庫設計60個技巧有感資料庫
- 設計模式有感設計模式
- 資料結構:初識(資料結構、演算法與演算法分析)資料結構演算法
- OO設計模式中的工廠模式設計模式
- [譯文] 初學者應該瞭解的資料結構: Tree資料結構
- [譯文] 初學者應該瞭解的資料結構: Graph資料結構
- 寫給Python初學者的設計模式入門Python設計模式
- 對響應式程式設計的懷疑 - lukaseder程式設計
- 基於物件導向(OO)的資料庫設計模式探討物件資料庫設計模式
- 人人都能讀懂的設計模式(2):結構型模式設計模式
- Banq:看了你的設計模式:Observer,有些疑問設計模式Server
- 資料結構-KMP模式演算法資料結構KMP模式演算法
- Flex屬性你真的搞清楚了嗎?我深表懷疑Flex
- Redis設計與實現閱讀總結(一)資料結構和物件Redis資料結構物件
- 設計模式你真的懂了嗎?設計模式
- 資料庫和OO資料庫
- [譯文] 初學者應該瞭解的資料結構:Array、HashMap 與 List資料結構HashMap
- 資料結構和演算法資料結構演算法
- 演算法和資料結構演算法資料結構
- 程式設計師的“黑客情懷”和“設計師情懷”程式設計師黑客
- 演算法、資料結構、與設計模式等在遊戲開發中的運用 (四):佇列(Queue)演算法資料結構設計模式遊戲開發佇列
- 初學者的程式設計自學指南程式設計
- 混合OO和Functional設計Function
- 《資料結構與演算法JavaScript描述》選讀:為什麼要學習資料結構和演算法資料結構演算法JavaScript
- 演算法和資料結構在JS中的運用(三)演算法資料結構JS
- 關於Proxy和Decorator設計模式的疑問設計模式
- JavaScript 的資料結構和演算法JavaScript資料結構演算法
- Java的資料結構和演算法Java資料結構演算法
- 你掌握了嗎?最強阿里面試126題:資料結構+併發程式設計+Redis+設計模式+微服務阿里面試資料結構程式設計Redis設計模式微服務
- 隨筆] 遊戲程式設計初學者常遇之疑問 :陳寬達 (轉)遊戲程式設計
- 對資料結構和演算法的總結和思考(六)--計數排序資料結構演算法排序
- 演算法、資料結構、與設計模式等在遊戲開發中的運用 (一):單例設計(Singleton Design)演算法資料結構設計模式遊戲開發單例
- 資料結構初識資料結構