Re: [请益] 这种情况有比 Decorator 更好的模式吗?

楼主: bill42362 (酒池肉林夜夜生科)   2013-10-14 16:38:46
: : 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 比较多。 @@"
不知道小弟这样的想法有没有再改进的空间,感谢大大协助!!

Links booklink

Contact Us: admin [ a t ] ucptt.com