PTT職涯區 / Soft_Job (軟體人)

Re: [分享] 面向對象編程從骨子裡就有問題

看板Soft_Job (軟體人)作者 (單車單)時間13年前 (2013/02/22 19:11), 編輯推噓12(12推 0噓 31→)
留言43則, 11人參與, 最新討論串4/12 (看更多)
※ 引述《mahoihei (Alvar)》之銘言： : 早上看到一篇對個人來說很衝擊性的文章 : http://goo.gl/z4Fa3 : 為什麼說是很衝擊性,因為我自己的編程基礎由oop開始的 : 而在oop design更是我在這個領域最喜愛的地方 : 想問大家對這篇文章有什麼見解?? 個人覺得物件導向對於大型程式的開發非常有用 在現在可以說非常必要 特別是-->類別方法非常非常好用. 比另外純函數好用多了 一般的函數需要"記得有什麼"函數 尤其是配合有自動完成的IDE下.. IDE都自動幫你查好了 比方說就拿最常用的I/O來看好了 如果我用檔案指標 我必須知道 有fopen()可以用 有fclose()可以用...之類的 但如果用fstream a; a.open(), a.close() 就不用特別記得"有哪些可用", IDE會幫你查. 這在大型的程式其實節省很多開發時間 省得一個一個去找有哪些的 即使要找 找同class 也比找整個.h檔方便多了 個人認為這其實就是物件導向非常強大好用的地方了 至於批評者說到繼承 我想紊亂的繼承維護起來很痛苦這是沒錯... 但其實...可以選擇盡量少用或不用吧... 就我所知,Linus也是討厭C++的人,我不知道他對其他OOP語言的看法 至於批評者講到只要一根香蕉卻得到整個叢林.... 我想就算寫C++的人也不會這麼蠢吧...該單函數就單函數, 應該不會特別去寫物件方法找自己麻煩, 比方說我要寫個swap我也不會神經病寫在class裡面 (ㄟ但是可能需要寫成template XD) 至於其他的物件導向語言我就不知道了... -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 60.248.182.130 ※ 編輯: amozartea 來自: 60.248.182.130 (02/22 19:13)
→
02/22 19:17, , 1F
就只是方便 如果只有一個main的程式也是有優點在啦
02/22 19:17, 1F
→
02/22 19:30, , 2F
如果你只是這樣用 就是不夠OOP喔
02/22 19:30, 2F
→
02/22 19:32, , 3F
OOP最好一層包一層 建構得越錯綜複雜越架構化越好
02/22 19:32, 3F
→
02/22 19:33, , 4F
100行的小程式 最好包得有一大堆class超過300行以行
02/22 19:33, 4F
→
02/22 19:34, , 5F
這就是嚴謹道地的OOP精神 別懷疑 很多人是這樣覺得
02/22 19:34, 5F
推
02/22 21:15, , 6F
我以為設計方法的目的是要低耦合耶
02/22 21:15, 6F
推
02/22 23:11, , 7F
一句話...凡事太盡...緣分早盡...
02/22 23:11, 7F
推
02/22 23:45, , 8F
在繼承中尋找生命的意義
02/22 23:45, 8F
推
02/23 00:06, , 9F
所以才有設計模式來解決一些很醜的設計
02/23 00:06, 9F
推
02/23 00:35, , 10F
要OOP也要架構用得若好，要不然，我有遇到過
02/23 00:35, 10F
→
02/23 00:35, , 11F
為什麼一個ASP.NET的GridView查詢，要執行4n次的SQL查詢
02/23 00:35, 11F
→
02/23 00:36, , 12F
因為它用了OO，所以必需累死資料庫
02/23 00:36, 12F
→
02/23 00:37, , 13F
或許是這專案的原始開發者它的設計有問題
02/23 00:37, 13F
→
02/23 00:37, , 14F
請問懂OOAD與OOP的人，這種情況該用什麼設計模式？
02/23 00:37, 14F
→
02/23 00:39, , 15F
才可以讓這樣的需求不用一個畫面查這麼多次的SQL？
02/23 00:39, 15F
推
02/23 00:40, , 16F
其實我對Design Patterns沒有很懂，所以才有這樣的疑問
02/23 00:40, 16F
→
02/23 00:42, , 17F
@astt88 一個gridview要跑4n次的SQL查詢 是他的設計問題
02/23 00:42, 17F
→
02/23 00:42, , 18F
@astt88 跟是否使用OOP無關，因為如果懂得SRP原則的話
02/23 00:42, 18F
→
02/23 00:43, , 19F
去拿取資料只會是一次性的工作，歸在一個物件責任歸屬上
02/23 00:43, 19F
→
02/23 00:43, , 20F
只能說這個設計是有問題，或者說設計者沒去認真思考過
02/23 00:43, 20F
推
02/23 00:44, , 21F
還有，上面的例子只是一個簡單的GridView
02/23 00:44, 21F
→
02/23 00:44, , 22F
Model與 Value Object 之間轉換的過程怎麼銜接
02/23 00:44, 22F
→
02/23 00:44, , 23F
若有Master Detail的查詢畫面架構，那要用什麼設計模式較好
02/23 00:44, 23F
推
02/23 00:46, , 24F
假設是希望點選Master data item之後，再去查詢細部detail
02/23 00:46, 24F
→
02/23 00:47, , 25F
你需要的就不是一般單純的GoF pattern了..當然也可說是變形
02/23 00:47, 25F
→
02/23 00:47, , 26F
DAO / transfer object assembler /
02/23 00:47, 26F
→
02/23 00:49, , 27F
facade --> service --> masterDao(key)--> detaildao
02/23 00:49, 27F
→
02/23 00:49, , 28F
--> transfer object assembler --> value list handler
02/23 00:49, 28F
→
02/23 00:49, , 29F
--> client bind gridview
02/23 00:49, 29F
→
02/23 00:50, , 30F
當然你也可以都不要這麼麻煩就用2~3個class依樣可以達成
02/23 00:50, 30F
→
02/23 00:50, , 31F
只是當你選擇在layering的過程中，想得愈多就越能應付變化
02/23 00:50, 31F
推
02/23 00:51, , 32F
謝謝，我再研究學習
02/23 00:51, 32F
→
02/23 00:52, , 33F
其實這種類似查詢4n次SQL的寫法，我在不同公司不同專案都
02/23 00:52, 33F
→
02/23 00:52, , 34F
有遇到過，不全然是OO的問題
02/23 00:52, 34F
→
02/23 00:55, , 35F
而且也有聽一些前輩與前同事討論過，他們也遇到過有人這樣
02/23 00:55, 35F
→
02/23 00:55, , 36F
用OO開發的程式，有這樣的問題
02/23 00:55, 36F
→
02/23 05:32, , 37F
要跑幾次查詢~要設計多少class~都沒有一定的準則吧?完全看
02/23 05:32, 37F
→
02/23 05:35, , 38F
需求要做到什麼樣的程度!不會變動的東西當然不必給彈性!
02/23 05:35, 38F
推
02/23 07:51, , 39F
推文在聊的，不就上篇文章談的什麼真OO假OO,更純的OO XDDDD
02/23 07:51, 39F
→
02/23 13:54, , 40F
2樓真的好酸 XD
02/23 13:54, 40F
推
02/23 14:24, , 41F
在專案開發中甚至維護中，沒有什麼東西是不會變動的
02/23 14:24, 41F
→
02/23 14:25, , 42F
若要說唯一不變的，就是這樣這個專案是我的負責的XD
02/23 14:25, 42F
推
02/25 12:27, , 43F
除非我離職不做了，要不然它就是我的責任
02/25 12:27, 43F
‣ 更多 amozartea 的文章
文章代碼(AID): #1H9r9CLP (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 4 之 12 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共12篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 amozartea 的文章
文章代碼(AID): #1H9r9CLP (Soft_Job)