posts - 80,comments - 749,trackbacks - 2

          已經好多天沒有寫blog了,原因是從南京轉到北京工作,還不太習慣,工作也很忙,上班時間不可以登陸blogjava這樣的網站,下班后又要會會多年沒見的一些老朋友(或者從來就沒有見過的朋友),回到酒店又沒有上網的條件——“上帝啊!上地大廈居然不能上寬帶!”

          隨著這兩天工作的深入,我們項目組遇到了一些問題,我將其中一個我認為很有價值又很有爭議的問題抽象出來寫在下面,供大家討論。

          項目組已經決定了要在后臺系統的組織上采用Facade+懶加載的形式。這個方案意味著要為Facade提供多個多級多層次的get方法,以便上層業務能根據自己的需要直接獲得關心的組件或關心的對象。并且如果在整個運氣期都沒有一個對象去get某個對象的話,后者很可能不被裝載,其它的對象和組件也只在需要時載入并運行。這個方案基本通過。現在的問題是有人提出少數組件應該具有伸縮性,所以應該采用容器+Service的形式實現,事實上Facade太死板不夠靈活,服務模式有很多能力是Facade模式所沒有的,所以應該加入。反對者(包括作者)認為既然已經有了一種解決方案,為什么還要另一種方案的參與呢。爭論使得項目組的所有成員在很長一段時間里(約一個多小時)都沒能做其它事情。現在我把這個難題交給blogjava的朋友們,希望回帖討論,謝謝。

          做平臺的泡泡

          posted on 2005-03-07 09:09 Brian Sun 閱讀(1250) 評論(3)  編輯  收藏 所屬分類: 軟件

          FeedBack:
          # re: 兩種實現方法的爭議
          2005-03-07 09:10 | Brian Sun
          我是這樣考慮的。我們先來看一個簡單的比喻。我們都知道圖有兩種基本的表示法——鄰接表和鄰接矩陣,兩種方法都可以全面的反映圖的信息,這意味著前一種表示法能做到的事情,后一種表示法也都能做到,同樣后一種表示法所做到的事情,前一種也不會做不到。所以圖只要以其中的一種表示法表示就可以了,(由于兩種表示法對不同操作有不同的反應性能,所以)除非有特殊的性能需求,否則不需要使某個圖同時具備這兩種實現方法。

          現狀也很類似,既然“Facade+懶加載”與“容器+Service”同時為解決問題的兩種方案,或者可以說是兩種實現方法,我們的系統又相對穩定,不會出現一會要加載5個服務,一會又變成50個的情況,所以我認為兩種方案不需要同時具備。此外,如果同時采用這兩種實現方法的話,很可能會在設計時出現這樣的尷尬局面:當程序員需要get一個對象時,他將面臨一個選擇,是將這個get方法放在容器里呢,還是放在門面上,或者,干脆,他兩個方法都提供,“既然后期需要大量重構,不如現在來點冗余代碼”的想法真的很深入人心。。。。。。

          做平臺的泡泡
            回復  更多評論
            
          # re: 兩種實現方法的爭議
          2005-03-07 14:07 | Samuel
          呵呵,看來咱們靠的很近阿,我在中關村軟件園,多聯系。
          你msn多少,給我來個郵件。samuel.net(at)gmail(dot)com  回復  更多評論
            
          # re: 兩種實現方法的爭議
          2005-03-07 14:47 | Brian Sun
          我的郵箱是
          briansun.vip@gmail.com

          我的MSN上班時間都開著
          javaboy2010@hotmail.com  回復  更多評論
            
          主站蜘蛛池模板: 安丘市| 五家渠市| 云安县| 新昌县| 彝良县| 盐津县| 盐亭县| 炉霍县| 澜沧| 县级市| 毕节市| 新宁县| 中阳县| 山阳县| 许昌市| 云林县| 宁远县| 葵青区| 无锡市| 木里| 虹口区| 理塘县| 咸阳市| 锦州市| 嵊泗县| 瑞丽市| 建水县| 囊谦县| 河北区| 正定县| 东台市| 闽侯县| 许昌市| 滨海县| 海伦市| 高碑店市| 屏东县| 平江县| 抚顺县| 宜州市| 炎陵县|