• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            sherrylso

            C++博客 首頁 新隨筆 聯(lián)系 聚合 管理
              18 Posts :: 0 Stories :: 124 Comments :: 0 Trackbacks

                    作為程序員,一直困擾我的一個問題是:一名優(yōu)秀的程序員,應(yīng)該是注重面向?qū)ο蠓治瞿芰Φ呐囵B(yǎng),還是注重算法分析能力的培養(yǎng)。我相信,這也是一個很多人面臨的問題。我的感覺是:很多system level的程序員更加側(cè)重于算法,而application level的程序員,更多的傾向于討論面向?qū)ο?。大家也可以看到,很多知名IT公司的面試,比如google,比如微軟,很喜歡考察程序員的算法方面的能力。而自從設(shè)計模式理論風(fēng)靡IT界以來,好像這些狀況有些改變,他們開始考察設(shè)計模式相關(guān)的問題,考察程序員面向?qū)ο蟮姆治瞿芰?。不可否認(rèn)的是,設(shè)計模式理論,其基于面向?qū)ο蟮睦碚摷夹g(shù),提供了開發(fā)者非常實效,有用的解決問題的模式。依賴于問題的上下文,應(yīng)用設(shè)計模式,開發(fā)者可以開發(fā)出更加"面向?qū)ο?的系統(tǒng)。
               設(shè)計一個復(fù)雜的系統(tǒng)的本質(zhì),就是:將復(fù)雜的問題分解成小的,為我們所理解的問題,然后分而治之。人類的智力是有限的,當(dāng)我們在面對一個復(fù)雜問題的時候,總會習(xí)慣于首先將他分解,分解到問題足夠的簡單,足夠為我們所理解,解決。事實上,無論是面向?qū)ο螅€是算法,它們都是分解復(fù)雜問題的方法與手段。是采用面向?qū)ο蟮姆椒ㄈシ治?,還是使用算法的分析方法,完全是由客觀的主體決定的。非常遺憾的是,這兩類分析方法是互斥的,排他的,你是不可能同時使用這兩種方法的分析解決問題。我們先看一個簡單的例子:
            問題的定義:client和server使用TCP/IP進行一個簡單的交互。
            算法的分解方法如下:


            問題空間被分解成為幾個執(zhí)行步驟,accept,connet,send,recieve。
            面向?qū)ο蟮姆纸夥椒?/u>如下:


            問題空間被分解成為幾個對象:c_connector, 主要負(fù)責(zé)建立TCP連接,在連接成功后,會得到一個c_socket_stream對象,該對象負(fù)責(zé)主要負(fù)責(zé)發(fā)送和接收網(wǎng)路數(shù)據(jù)。c_acceptor,負(fù)責(zé)監(jiān)聽網(wǎng)絡(luò)連接請求,在一個TCP連接成功建立后,返回給調(diào)用者一個c_socket_stream。
            兩者的區(qū)別在于:兩者分解方法的著重點是不同的,算法的分析方法強調(diào)的是事物內(nèi)部各類事件之間的順序,依賴,耦合關(guān)系。算法所關(guān)心的是事件本身,例如上例中:它關(guān)心的是send,recv這樣發(fā)生在事物內(nèi)部的事件,以及它們之間的調(diào)度關(guān)系。面向?qū)ο蟮姆治龇椒ㄔ谟趶娬{(diào)的是事物內(nèi)部各類客觀的主體,以及它們之間的相互協(xié)助。
            從這點上可以看到:在分解一個問題的時候,算法偏重于微觀,面向?qū)ο髠?cè)重于宏觀;算法偏重于細(xì)節(jié),面向?qū)ο髠?cè)重于整體??梢钥吹?,我們很容易得出這樣的結(jié)論:當(dāng)面對一個復(fù)雜的問題的時候,我們的直覺會告訴我們,我們會更加傾向于使用面向?qū)ο蠓椒ɡ碚搧矸治鰡栴}。這也是幾十年來面向?qū)ο蟮能浖嵺`經(jīng)驗告訴我們的真理。在計算機應(yīng)用開發(fā)領(lǐng)域,面向領(lǐng)域問題本身的復(fù)雜性(這包括許多方面:比如你的需求在不斷變化,你的應(yīng)用方式在不斷變化等等),決定了其更適合使用面向?qū)ο蟮姆椒▉矸治鰡栴}。面向?qū)ο蟮能浖到y(tǒng)會更加的富有彈性,更加的能適應(yīng)這種快速的變化。
                 如何做面向?qū)ο蟮脑O(shè)計分析?關(guān)鍵在于:
                 1) 對復(fù)雜問題的抽象,將復(fù)雜的問題抽象成為一組對象,就是我們熟知的objects。object是面向?qū)ο筌浖到y(tǒng)的行為主體。抽象也意味著我們應(yīng)該忽略細(xì)節(jié)的東西,注重整體的東西。
                 2)組織這些objects,使他們形成具有一定結(jié)構(gòu)的整體。比如:通過繼承,使它們成為父子關(guān)系,通過組合,使它們具有合作依賴關(guān)系。通過組織這些objects,我們更加能清楚地看到這些這些objects公共的行為和屬性。這就形成了面向?qū)ο筌浖玫幕A(chǔ)。
                很多人說:算法是程序設(shè)計的靈魂,但是我們也不能忘記;面向?qū)ο?,幫助我們能夠更加容易理解問題復(fù)雜性的本質(zhì)?;蛟S算法與面向?qū)ο蟮淖罴训慕Y(jié)合點在于: 使用面向?qū)ο蟮姆椒ǚ纸鈫栴},而使用精良的算法解決問題。

            posted on 2007-06-24 22:31 愛上龍卷風(fēng) 閱讀(1879) 評論(7)  編輯 收藏 引用

            Feedback

            # re: 面向?qū)ο蠓治龇椒ㄅc算法 2007-06-24 23:11 eXile
            算法分析和面向過程的分析好象還不太一樣吧?
              回復(fù)  更多評論
              

            # re: 面向?qū)ο蠓治龇椒ㄅc算法 2007-06-25 12:48 clichengui
            不太對吧  回復(fù)  更多評論
              

            # re: 面向?qū)ο蠓治龇椒ㄅc算法 2007-06-25 23:13 愛上龍卷風(fēng)
            算法本身的定義是:一種循序漸進解決問題的過程,一種為在有限步驟內(nèi)解決問題而建立的可重復(fù)應(yīng)用的計算過程。
            如果我們用算法的思維方式來分解問題,會使我們拘泥于細(xì)節(jié)。
            而面向過程,那是方法論上的定義,不是這里所討論的。
            更確切地講,這里是討論的是:
            面向?qū)ο蟮姆纸夥椒?vs algorithmic 分解方法



              回復(fù)  更多評論
              

            # re: 面向?qū)ο蠓治龇椒ㄅc算法 2007-06-26 09:33 子寒
            “非常遺憾的是,這兩類分析方法是互斥的,排他的,你是不可能同時使用這兩種方法的分析解決問題” 不是這樣的吧 不同層次的問題 用不同的方法  回復(fù)  更多評論
              

            # re: 面向?qū)ο蠓治龇椒ㄅc算法 2007-06-26 22:40 愛上龍卷風(fēng)
            不過在"分解問題"這個層次上,從思維方式的角度考慮,我們可以用面向?qū)ο蟮乃季S方式,或者算法式的思維方式  回復(fù)  更多評論
              

            # re: 面向?qū)ο蠓治龇椒ㄅc算法 2007-06-28 09:41 SuperPlayeR
            建議閱讀一下《Unix編程藝術(shù)》
              回復(fù)  更多評論
              

            # re: 面向?qū)ο蠓治龇椒ㄅc算法 2008-01-07 23:36 abettor.org
            我的感覺是:很多system level的程序員更加側(cè)重于算法,而application level的程序員,更多的傾向于討論面向?qū)ο蟆?br>
            ——同意這句。
            有時候感覺那些所謂“GOOGLE面試題”太矯情了,而有些人的對象設(shè)計的又太牽強了。  回復(fù)  更多評論
              

            久久成人18免费网站| 久久久国产精华液| 女人香蕉久久**毛片精品| 91亚洲国产成人久久精品| 久久中文精品无码中文字幕| 中文无码久久精品| 9999国产精品欧美久久久久久| 伊人色综合九久久天天蜜桃| 2021久久国自产拍精品| 久久久黄色大片| 久久精品国产99国产电影网| 亚洲欧洲久久久精品| 国产亚洲美女精品久久久久狼| 久久九九久精品国产| 久久精品中文无码资源站| 亚洲国产精品综合久久一线| 久久精品男人影院| 久久久噜噜噜久久熟女AA片| 久久综合视频网站| 91精品国产高清久久久久久国产嫩草| 久久91精品国产91| 亚洲国产二区三区久久| 久久久久无码精品国产| 99精品国产综合久久久久五月天| 久久天天躁狠狠躁夜夜av浪潮| 久久精品国产精品国产精品污| 久久午夜伦鲁片免费无码| 久久精品国产亚洲av麻豆图片| 一本久久精品一区二区| 久久一区二区三区99| 久久免费视频6| 日韩美女18网站久久精品| 久久久久九国产精品| 香蕉99久久国产综合精品宅男自 | 久久精品成人免费网站| 久久精品水蜜桃av综合天堂| 无码AV波多野结衣久久| 色综合久久久久无码专区| 伊人久久综合无码成人网 | 66精品综合久久久久久久| 久久er热视频在这里精品|