Re: 今天被問倒了...

看板OOAD作者Schelfaniel (Schelfaniel)時間15年前 (2009/07/10 23:06)推噓2(2推 0噓 3→)

留言5則, 3人參與討論串8/13 (看更多)

※ 引述《PsMonkey (痞子軍團團長)》之銘言： : 版主說，如果我不回 po 就要浸我水桶，所以我只好... [完全誤] 板主可以這樣喔?? : 我不是個認真的技術者算是實務者? XDD : 所以 OOP 還是 OOA/D，都沒有認真、完整的唸過 : 更不用說 UML 了... 棍... 那到底是哪一國語言... UML 在台灣我不確定哪邊有用比較多，但，它有像 class diagram，都寫出 class 了，可見就是給物件導向式的程式用的，其它有些是比較泛用的。 : 同理 Design Pattern 也... [默] C++，Java 用得比較多...對有些比較傳統的語言，不需要太多中間層，其實我總覺得這 Design Pattern，多少也是因為物件導向的特性而發展的 @.@ : 在我的觀點 or 學習 OOP 的過程來說 : 結構化（也許就是你說的程序導向）程式語言 : 跟 OOP 的距離並沒有那麼遙遠同意 : 以「封裝」這個層級的角度來看，根本就一樣 : 差別在於用 OOP 的程式句型，呼叫一個 method 得有主詞 : 然後變數通常歸屬於某個主詞下，變數的 scope 通常就跑不出去算是函式有歸屬感，成員變數也有歸屬感 :QQ : （OS：咪的... 要遵守單一責任原則，問題是... : 切出來的這個責任到底要歸誰？ : 又不能仿效政府官員踢皮球... [炸]）切出來的就用 Design Pattern 的 Bridge 呀，Moderator 呀等等的 :QQ 反正就是再切一個物件或是介面出來 :QQ : 接下來是我最想回的部份（OS：靠... 那上面這一大沱廢話是...） : 「倒不是說OO就沒有空隙，而是因為OO就算有空隙， : 也能在系統發展的先期就顯露出來。」 : 我其實不覺得，有了 OOP、發展出 OOA/D 技術 : 元件跟元件之間的組合順暢度，在系統發展的前期就能顯露出來 : 當然，以我的能力跟經驗，講這句話實在太超過了 : 只能說，我不會對這件事情這麼樂觀其實我覺得說真的問題啦，都是在使用者需求比較多，寫到後來發現架構有問題?? 感覺上比較像是前期測試架構就沒測好，這方面我覺得和 OOP 沒關係， OOAD 或許有一點關係。 : XP 工法可以說抓著一個囧況，因此走向極端 : 做出成品之後才會知道真正需要什麼 : 算不算前期後期，我不知道 : 我只知道，明明我把一個元件開發好了 : 但是常常卻又得為了另外一個元件而修改，甚至砍掉重練 : 又或著，程式寫出來 : 才發現這邊要 extract method，那邊要 extract interface : method push 來 push 去，然後 refactoring 這種書就出來了 <囧> : interface 用來用去，發現好像都是那幾招 : 然後 design pattern 這種書就出來了 <囧> : 當然，這也可以說，是 SA/SD 的功力問題 : 如果 SA/SD 火候十足，隨時可以四人幫上身 : 那 refactoring 不會警告你沒把握不要公佈 interface : 瀑布也不會消失不見....... : 講的暴力一點，如果真的在前期就能顯露出來 : 那一卡車的 framework，除了懶惰的因素外 : 也沒有使用的必要了，不是嗎？ : 重刻一個自己的 framework : 能完全符合自己需求、又不用搞懂別人的東西，多好!! : 我沒有用結構化程式語言寫過大一點的程式（至少也要超過 2K line） : 可能沒啥本錢講的很肯定 : 我只能說，有了 OOP, OOA/D : 或許相較過去，我們能夠比較快樂的寫出比較大的程式 : 但是，根本性的問題，依然存在其實，我看過很大的 COBOL 程式，我覺得一開始架構好的話，就算用 COBOL 這個一堆 GO TO 的語言，還算不會太難懂，當然很多地方是用 Copy/Paste 硬寫的 @@ 但這樣的程式，竟然也撐了 30 年了，也算很厲害了，碰過一堆需求變更調整的 ( 上線之後修改 )，也就是它是在程式一面運作，仍然一面修改的情形之下。物件導向這方面最麻煩，很容易牽一髮而動全身，要改一個東西，要連帶改一堆東西，加上現代化的架構，有時還要改一堆 xml，讓那些寫 COBOL 的人，反而過來說，不就改一點點就好了，怎麼會這麼麻煩。 ( 當然 COBOL 麻煩的地方也是有的 ) 其實一開始，物件導向剛出來時，大家都很瘋物件導向，覺得有它就能解決一切的問題，但是用久了之後，它的問題漸漸就被發掘出來了，甚至我在看 Haskell 時，也有人自豪得說 Haskell 的 Type 系統，比物件系統好。而最近也看到明明在 JVM 上跑，和物件非常有關聯，但實際上又是函數語言的 clojure，當然另一方面微軟也不是省油的燈， F# 這個第一線函式語言的推出，證實微軟也不會看輕函數語言這市場，可是我自己覺得，函數語言，也不會是沒缺點的就是了。其實我覺得像 JVM 或是微軟 CLR，提供一堆讓程式師選擇語言，算是比較能夠符合個人喜好，又能夠團隊運作的模式，畢竟，程式設計師有時需要的不只是技術或管理，而是動力和熱誠，讓程式設計師本身處於自己舒適的環境之下開發，而不要綁手綁腳，限東限西，要你乾坤大挪移也不能用，降龍十八掌也不能用，這樣出去必定功力下降，士氣下滑嘛。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.32.74.159