Re: [請益] 這種情況有比 Decorator 更好的模式嗎?

看板OOAD作者bill42362 (酒池肉林夜夜生科)時間10年前 (2013/10/14 16:38)推噓0(0推 0噓 15→)

留言15則, 3人參與討論串4/6 (看更多)

: : A { : : display(); : : zoom(); : : } : : B { : : display(); : : play(); : : } : : C { : : display(); : : copy(); : : } : 權限決定是否加上的 share(), vote(), edit(), delete() : 比如甲因為是作者，所以為他加上 edit() 和 delete() : 同一個物件乙看到時可能只有 vote() : 而丙因為是甲的好友，所以可以 share(), vote() : 推 legendmtg :你應該先考慮把share() vote edit()這些function 10/13 04:24 : → legendmtg :做成接收A B C這些type的non-member function 10/13 04:25 : 推 tails32100 :個人想法：就算動態加上去一樣，在調用時一樣要判斷 10/13 12:28 : → tails32100 :直接把要用的function全寫進去，判斷寫在裡面會比較 10/13 12:29 : → tails32100 :單純好懂 Orz 10/13 12:30 : 推 qrtt1 :看起來沒有動態的必要，這是有沒有權限的問題啊xd 10/13 20:18 : → qrtt1 :你需要的是一個好的權限架構吧（思 10/13 20:33 : 推 legendmtg :提供set/get function就好了啊為什麼要做成public? 10/13 21:10 小弟這個系統目前是實作在網頁上所以先試著從Q大的權限架構這個點來思考權限我想到的實作方法有兩種 1) 讓 ABC 都擁有 share(), vote(), ...method，將執行的動作送至伺服器，由伺服器判斷權限並回傳結果。缺點是流量會非常大，伺服器不夠好可能會有點辛苦。這其中又分為兩種作法: i. 使用 non-member function 或是建立另一個接受 ABC 為參數的物件專門處理這些行為。 ii. 將所有的 ABC 物件都加上這些 methods，但這樣會造成大量重複的程式片段，以後要增修都很麻煩，暫不考慮。 2) 將權限判斷放在 client 端，藉以減少流量，但事實上為了防止偽 client，還是要在 server 端再判斷一次。這也分兩種方法: i. 在 new 物件時同時向伺服器取得權限資訊，並只為物件加上允許的 methods。可惜在各種搜尋下都找不到適合的設計模式，這部份還請大大多多幫忙。TT ii. 使用類似 1) 的方法，但是在取得權限資訊後將不允許的行為從 UI 部分鎖住。目前感覺 2-ii 的方法是可行性最高的，也可以達到節省流量的效果。 To L 大: 印象中有看過一篇文章，建議 set/getter 除非是有再處理效果，如: setValue(a) { this.a = a/2; }。不然如果成對出現時語意上跟直些設成 public 差別不大。所以我遇到這種情況通常都是設成 public 比較多。 @@" 不知道小弟這樣的想法有沒有再改進的空間，感謝大大協助!! -- 想你的時候不一定能告訴你如果不告訴你也能會意那我們就是有真正的默契 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 121.215.129.5