果然被淘汰了，和我想的差不多，原因是我覺得它太復(fù)雜了，我喜歡那種一看上去就清晰簡單的東西，而且要容易理解。一個(gè)好的架構(gòu)應(yīng)該可以抽象成現(xiàn)實(shí)生活中有的“東西”，這樣理解起來就容易多了。
我學(xué)“面向?qū)ο笤O(shè)計(jì)”的時(shí)候，發(fā)現(xiàn)一個(gè)問題，那就是對(duì)象的“方法”問題，比如對(duì)象要是人的話，他有一個(gè)“提交”，或者是“檢查”的方法，那是很容易理解的。但是比如有個(gè)“表單類”，其中他的方法“添加”。我覺得它這個(gè)方法是“被動(dòng)”的，因?yàn)楸韱巫约翰⒉粫?huì)“添加”，施加給它這個(gè)“動(dòng)作”，或者是“方法”的，應(yīng)該是個(gè)人。所以我認(rèn)為，我們建模的時(shí)候?yàn)槭裁床话岩粋€(gè)過程抽象為現(xiàn)實(shí)生活中的過程呢，也許它的性能會(huì)低一些。雖然我還沒有具體去實(shí)踐，也還沒有學(xué)過什么J2EE，但是我把我的想法說說：
比如架構(gòu)一個(gè)系統(tǒng)，要涉及到權(quán)限，要涉及到功能的“開”，“關(guān)”，最基本的做法，我們做每一個(gè)操作之前，總是要查詢“這個(gè)功能被系統(tǒng)打開了或者是關(guān)閉了沒”，“我們是不是有這個(gè)權(quán)限”，很自然的，比如是個(gè)注冊系統(tǒng)，我們在執(zhí)行“添加”這個(gè)動(dòng)作之前，都必須用到兩個(gè)方法，第一個(gè)檢查這個(gè)“注冊”功能是不是正被開放使用，第二個(gè)，我們是不是有這個(gè)“權(quán)限”進(jìn)行“添加”操作？那這兩個(gè)類，我們應(yīng)該放在哪個(gè)類里面去呢，也許我們可以把他分成兩個(gè)類（權(quán)限類，功能類），然后在“注冊類”里面加上這兩個(gè)方法，在執(zhí)行“添加”之前操作他們。我覺得這樣增加了他們之間的“耦合”，也顯得很混亂，在一個(gè)類里面執(zhí)行這些操作，是不是把“注冊類”這個(gè)靜的東西動(dòng)態(tài)了？執(zhí)行這些操作的應(yīng)該是個(gè)人才對(duì)啊？就象在現(xiàn)實(shí)世界中，我們填寫完一張注冊表之后，我們并不會(huì)直接去“檢查”，“添加”他，我們會(huì)把他交個(gè)一個(gè)這方面的人，然后這個(gè)人會(huì)檢查，我是不是有這個(gè)權(quán)限？我填寫的完整沒有？然后他跟“注冊類”打交道。也就是,用戶――>“負(fù)責(zé)注冊模塊的人”――>注冊類。這樣打交道。
權(quán)限和功能問題：我們要進(jìn)行操作時(shí)，先找個(gè)負(fù)責(zé)這個(gè)操作的人，然后他告訴我，比如，“這個(gè)功能被關(guān)閉了”，“你的操作已經(jīng)成功了”，之類，我們不直接跟類打交道，因?yàn)槲覀儾荒艹洚?dāng)每方面的“專家”
這樣做的好處，松耦合，也省的每次執(zhí)行操作之前都要在方法里面嵌套方法，我們可以等用戶登陸的時(shí)候，就找到那個(gè)相關(guān)的人，把系統(tǒng)的功能開放了哪些和這個(gè)人可以進(jìn)行的操作記錄在表里，進(jìn)行操作的時(shí)候就不必再查數(shù)據(jù)庫了，應(yīng)該更快些？然后用戶退出的時(shí)候，就刪除相關(guān)的記錄？
我覺得MVC模式里面的C，有時(shí)候他就充當(dāng)了“這個(gè)人”的角色，但其實(shí)這個(gè)人可以分的更細(xì)些。
這些問題我也是剛想的，你們的想法是？或者，說說這樣做的缺陷
|
|