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

: 早上看到一篇對個人來說很衝擊性的文章 : 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) 至於其他的物件導向語言我就不知道了... -- ◆ From: 60.248.182.130
※ 批踢踢實業坊(ptt.cc)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1361531468.A.559.html

→ leiyan:就只是方便 如果只有一個main的程式也是有優點在啦 02/22 19:17

→ erspicu:如果你只是這樣用 就是不夠OOP喔 02/22 19:30

→ erspicu:OOP最好一層包一層 建構得越錯綜複雜越架構化越好 02/22 19:32

→ erspicu:100行的小程式 最好包得有一大堆class超過300行以行 02/22 19:33

→ erspicu:這就是嚴謹道地的OOP精神 別懷疑 很多人是這樣覺得 02/22 19:34

推 codemonkey:我以為設計方法的目的是要低耦合耶 02/22 21:15

推 LetDogDay:一句話...凡事太盡...緣分早盡... 02/22 23:11

推 f1234518456:在繼承中尋找生命的意義 02/22 23:45

推 snaketsai:所以才有設計模式來解決一些很醜的設計 02/23 00:06

推 astt88:要OOP也要架構用得若好，要不然，我有遇到過 02/23 00:35

→ astt88:為什麼一個ASP.NET的GridView查詢，要執行4n次的SQL查詢 02/23 00:35

→ astt88:因為它用了OO，所以必需累死資料庫 02/23 00:36

→ astt88:或許是這專案的原始開發者它的設計有問題 02/23 00:37

→ astt88:請問懂OOAD與OOP的人，這種情況該用什麼設計模式？ 02/23 00:37

→ astt88:才可以讓這樣的需求不用一個畫面查這麼多次的SQL？ 02/23 00:39

推 astt88:其實我對Design Patterns沒有很懂，所以才有這樣的疑問 02/23 00:40

→ kimkao:@astt88 一個gridview要跑4n次的SQL查詢 是他的設計問題 02/23 00:42

→ kimkao:@astt88 跟是否使用OOP無關，因為如果懂得SRP原則的話 02/23 00:42

→ kimkao:去拿取資料只會是一次性的工作，歸在一個物件責任歸屬上 02/23 00:43

→ kimkao:只能說這個設計是有問題，或者說設計者沒去認真思考過 02/23 00:43

推 astt88:還有，上面的例子只是一個簡單的GridView 02/23 00:44

→ kimkao:Model與 Value Object 之間轉換的過程怎麼銜接 02/23 00:44

→ astt88:若有Master Detail的查詢畫面架構，那要用什麼設計模式較好 02/23 00:44

推 kimkao:假設是希望點選Master data item之後，再去查詢細部detail 02/23 00:46

→ kimkao:你需要的就不是一般單純的GoF pattern了..當然也可說是變形 02/23 00:47

→ kimkao:DAO / transfer object assembler / 02/23 00:47

→ kimkao:facade --> service --> masterDao(key)--> detaildao 02/23 00:49

→ kimkao:--> transfer object assembler --> value list handler 02/23 00:49

→ kimkao:--> client bind gridview 02/23 00:49

→ kimkao:當然你也可以都不要這麼麻煩就用2~3個class依樣可以達成 02/23 00:50

→ kimkao:只是當你選擇在layering的過程中，想得愈多就越能應付變化 02/23 00:50

推 astt88:謝謝，我再研究學習 02/23 00:51

→ astt88:其實這種類似查詢4n次SQL的寫法，我在不同公司不同專案都 02/23 00:52

→ astt88:有遇到過，不全然是OO的問題 02/23 00:52

→ astt88:而且也有聽一些前輩與前同事討論過，他們也遇到過有人這樣 02/23 00:55

→ astt88:用OO開發的程式，有這樣的問題 02/23 00:55

→ andymai:要跑幾次查詢~要設計多少class~都沒有一定的準則吧?完全看 02/23 05:32

→ andymai:需求要做到什麼樣的程度!不會變動的東西當然不必給彈性! 02/23 05:35

推 Assyla:推文在聊的，不就上篇文章談的什麼真OO假OO,更純的OO XDDDD 02/23 07:51

→ AntaresStar:2樓真的好酸 XD 02/23 13:54

推 astt88:在專案開發中甚至維護中，沒有什麼東西是不會變動的 02/23 14:24

→ astt88:若要說唯一不變的，就是這樣這個專案是我的負責的XD 02/23 14:25

推 astt88:除非我離職不做了，要不然它就是我的責任 02/25 12:27