我不是個喜歡”深究“的權(quán)威型工程師,,所以一些觀點并不敢保證精準和正確,。我喜歡就自己的經(jīng)驗,談一下個人的理解,,如果說錯什么,,敬請批評指正。
1)關(guān)于面向“類”和面向“對象”的問題
面向?qū)ο缶幊淌欠N編程范式,,在提出這種范式之初,,關(guān)心的東西只有“對象”和“對象間的消息傳遞機制”。而隨著面向?qū)ο蠓妒皆谡Z言層面的不斷探索,,于是出現(xiàn)了“類”的概念,,有了面向?qū)ο笕筇攸c“封裝”、“繼承”和“多態(tài)”?,F(xiàn)在有不少人在追本朔源,,說“面向?qū)ο蟆爆F(xiàn)在變成了”面向類“,已經(jīng)不再是它的初衷了,,面向?qū)ο笞呦蛄隋e誤了方向,,應(yīng)該反思。
反思是應(yīng)該的,,追本朔源可以幫助我們站在一個更高的角度來看問題,。但結(jié)論我并不認同,私以為”類“的概念的提出,,是對”面向?qū)ο蟆霸趯嵺`方面的一個很好的補充和完善,,它屬于”面向?qū)ο蟆袄砟畹摹睂嵺`“,,而且是一個非常好非常精彩的實踐。我承認在當今的實踐中,,面向”對象“實在太容易變成面向”類“了,,類的作用非常重要,可是我并不覺得提高類的重要性對編程帶來了多大的麻煩,。類的作用變得如此之大,,我覺得并非”走火入魔,誤入歧途“,,而是”自然發(fā)展,自然選擇“,。沒必要為”類“的重要性太高而糾結(jié),。
2)設(shè)計模式的問題
設(shè)計模式在過去的一段時間里,溫度有點過高了,,甚至在很多初學(xué)者看來,,似乎以”設(shè)計模式“為編程技巧的終點了,有點把它當《九陰真經(jīng)》了,。其實設(shè)計模式是個什么東西呢,?設(shè)計模式是在”面向?qū)ο蟆斑@種編程范式的基礎(chǔ)上,提練的一套編程技巧,,解決的是”面向?qū)ο缶幊虝r,,如何去抽象類,設(shè)計類“這個問題,。
面向?qū)ο缶幊?,?yīng)該分為”O(jiān)OA“、”O(jiān)OD“和”O(jiān)OP“三個步驟,。OOP是和具體語言相關(guān)的,,不同語言的語法是有差異的,比如c#,、as3,、java、ruby,、python等都是面向?qū)ο笳Z言,,但不同語言的語法差異還是比較大的。OOP是大多數(shù)工程師們特別關(guān)心的問題,,因為這是他們跨入編程圈會遇到的第一個問題,。很多人會誤以為它是面向?qū)ο缶幊痰娜浚貏e是只看過語言基礎(chǔ)教程的工程師,。其實不是,,而且OOP甚至不是面向?qū)ο缶幊痰闹攸c,,OOA和OOD才是。
OOA和OOD是面向?qū)ο蠓治龊兔嫦驅(qū)ο笤O(shè)計,。將客觀世界的看得見的實物或者邏輯層面的看不見的物件,,轉(zhuǎn)換成程序中的一個個對象,用屬性和方法來描述對象,,這種轉(zhuǎn)換的過程我們管他叫”抽象“,,也可以叫做OOA。這里有個問題就是:同樣的一個需求,,你可以做完全不同的抽象,,設(shè)計出幾套完全不同的對象。有些方案好,,有些方案可能不好——雖然他們都能解決問題,,但可能在可維護性上(健壯性、可讀性,、可擴展性等等)有非常大的差異,。
于是有了OOD,有了設(shè)計模式,。設(shè)計模式的作用是告訴你”面對類似xxxx這樣的需求,,你可以抽象成這么幾個類:A和B,其中A有哪些方法和屬性,,B有哪些方法和屬性,,他們?nèi)绾闻浜瞎ぷ鳌TO(shè)計成A和B這樣的類,,可以為你帶來什么什么樣的好處“,。
雖然設(shè)計模式之父GOF四人組介紹了23種設(shè)計模式,但事實上,,常用的設(shè)計模式只有那么幾種,。而且每本設(shè)計模式的書,都會告訴你,,不要為了設(shè)計模式而設(shè)計模式,。這東西只是用來幫助你解決一些設(shè)計問題的,而且以我的經(jīng)驗來說,,設(shè)計模式既不難理解,,也并不是那么必要,離《九陰真經(jīng)》的定位差遠了,。學(xué)學(xué)有必要,,但完全不用對這玩意兒過于糾結(jié),甚至不用過于上心,。如果經(jīng)驗慢慢積累夠了,,在OOA的時候,,不必借助設(shè)計模式,你也可以很好地OOD了,。
3)面向?qū)ο笞钪匾?,卻又容易被忽視的問題——編程技巧
不知道編程技巧算不算是OOP的一部分,算或不算都有道理,,因為它雖是編程方面的技巧,,卻和程序語言的關(guān)系不大,可以跨語言通用,。面向?qū)ο笤趯崙?zhàn)中,,最大的難點應(yīng)該在如何讓對象”高內(nèi)聚低耦合“。高內(nèi)聚說白了,,就是在抽象對象時,,能讓你抽象出來的對象”屬性和方法能高度重用“,這個重用或許是自己調(diào)自己,,或許是別的對象調(diào)自己,被調(diào)用的機會越多,,內(nèi)聚得越厲害,。如果一個對象的某些屬性和方法被調(diào)用的次數(shù)很少,可以考慮將其拆解一下,,拆成兩個或更多的類,,借此提高這些對象的內(nèi)聚性。
而低耦合就好理解多了,,一個對象對其他對象的依賴性越低,,知道的越少,耦合度越低,。如何降低耦合度,,是需要編程技巧的,雖然OOA和OOD也能幫助解決這個問題,,但編程技巧上也需要一些方法,,比如盡量私有、通過命令模式拆分開m和c從而解除對象間的直接調(diào)用,、增加常量減少變量等等等等,。
在編程技巧方面的學(xué)習(xí),重要性和實用性都比設(shè)計模式更高,。而這方面其實又不會像設(shè)計模式這樣有書可以看,,也不是通過自己頓悟能夠悟出來的,最有效的方法是去看別人的代碼,,看高質(zhì)量開源框架的源碼,,多學(xué)不同領(lǐng)域的知識,,融會貫通。
4)面向?qū)ο缶幊毯秃瘮?shù)式編程
大概在三四年前,,面向?qū)ο缶幊處缀跻恢卤豢春煤湍ぐ?。然后在過去一兩年,似乎對面向?qū)ο缶幊痰馁|(zhì)疑變多了,,有些工程師很推崇函數(shù)式編程了,。對于函數(shù)式編程,我沒有研究過,,所以不好發(fā)表意見,。這里只說一點私人看法,如果說錯了,,請見諒,。
函數(shù)式編程的歷史很悠久了,和面向?qū)ο缶幊谭妒揭粯?,也是一種基本的編程范式,,圍繞這種范式也產(chǎn)生了一系列的編程技巧:比如傳參時參數(shù)有默認值、參數(shù)數(shù)量可變,、裝飾器等等,,它有和面向?qū)ο蟛煌年P(guān)注點和相應(yīng)的優(yōu)勢。但,,私以為面向?qū)ο筮€是大勢所趨,,從主流語言的市場份額、市面上的書籍數(shù)量,、思維習(xí)慣易上手性和主流的編程范式等多個方面來說,,面向?qū)ο髴?yīng)該都是優(yōu)勢明顯的。
很多人在說面向?qū)ο笥泻芏鄦栴},,不好,。而函數(shù)式編程可以解決這些問題。私以為,,面向?qū)ο蟊旧砥鋵崙?yīng)該是非常好的,。面臨的一些問題,會不會是因為很多工程師缺少編程技巧而造成的,?因為面向?qū)ο笫侵髁?,所以使用的人多,暴露的問題也就越明顯,,就像windows的病毒遠比mac os多一樣,,原因并非mac os安全性高,而是windows被黑的太多了,。
所以函數(shù)式編程,,如果有時間的話,,可以學(xué)習(xí)一下,豐富自己的編程技巧,,但正常情況下,,我建議還是隨大流,專心把面向?qū)ο缶幊掏婧冒伞?/p>