• <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>
            隨筆 - 119  文章 - 290  trackbacks - 0

            博客搬家了哦,請移步
            叫我abc

            常用鏈接

            留言簿(12)

            隨筆分類

            我的博客

            搜索

            •  

            積分與排名

            • 積分 - 304422
            • 排名 - 84

            最新評論

            閱讀排行榜

            讀完了討論復雜度的章節(《UNIX編程藝術》),被教導兩個原則:
            1,復雜度在所難免,除去代碼量這種太過直觀的衡量不說,人類更傾向于降低實現復雜度,而非接口復雜度。
            2,各種分離的接口模式仍然適用,但是如果實在不能完成渴望的功能,才考慮集成到一個IDE下。

            軟件課程要做的game項目進展得比較順利,由于已經有了一個demo,得以熟悉game軟件大體的框架,此外UML恰當的運用到設計中,使得各種對象間的接口問題得以輕松解決。
            不過,team work的一個基本前提,就是“認識一致”吧。如果某個partner沒有了解到框架如何運作,那么寫起代碼來,應該是比較乏味的。
            經驗有1,無耦合的對象間交互。一個對象,盡可能不包含以其他對象作為實參的成員函數。前一個demo就是違反了這點,結果接口設計以及實現都不厭其煩。所有的對象交互問題都離開對象本身,而丟到一個processor里面,由processor根據兩對象的類型,驅動對象的恰當方法,完成交互。
            目前的麻煩也有1個:
            problom.jpg
            如上,關鍵是我現在不能過多預料它們的生存期問題。resource manager最長,但是有可能some thing的時間要比some work processor短。如何解決?
            posted on 2006-10-27 20:04 LOGOS 閱讀(987) 評論(0)  編輯 收藏 引用
            国产日产久久高清欧美一区| 久久免费视频1| 久久精品国产亚洲AV嫖农村妇女 | 国产精品内射久久久久欢欢| 久久笫一福利免费导航 | 国产AⅤ精品一区二区三区久久| 88久久精品无码一区二区毛片| 久久国产免费直播| 亚洲精品99久久久久中文字幕| 国产欧美久久一区二区| 久久免费大片| 国产精品熟女福利久久AV| 久久妇女高潮几次MBA| 久久亚洲国产精品一区二区| 久久亚洲精品成人AV| 国产A三级久久精品| 偷窥少妇久久久久久久久| 人妻中文久久久久| 亚洲人成无码久久电影网站| 波多野结衣中文字幕久久| 国产99精品久久| 蜜桃麻豆www久久| 亚洲乱码中文字幕久久孕妇黑人 | 国产三级精品久久| 国产亚洲精品美女久久久| 一级女性全黄久久生活片免费| 999久久久免费国产精品播放| 国内精品久久久久伊人av| 亚洲国产精品无码久久久不卡| 久久久艹| 伊人久久大香线蕉av一区| 亚洲人成无码www久久久 | 久久99精品久久久大学生| 中文字幕无码久久久| 欧美精品福利视频一区二区三区久久久精品 | 久久亚洲中文字幕精品有坂深雪| 欧美日韩精品久久久久| 久久国产精品波多野结衣AV| 久久久久久久波多野结衣高潮| 美女久久久久久| 久久精品视频一|