Re: [問題] this 在什麼情況下會等於NULL??

看板C_and_CPP作者 (小西風最乖了*^^*)時間14年前 (2011/07/25 17:29), 編輯推噓4(4推 0噓 11→)
留言15則, 5人參與, 最新討論串8/8 (看更多)
你好，我很後悔在這個版提設計模式，因為這個跟 C++ 本身沒有直接關係。 徵得版主有條件同意以後稍微回一下好了。我個人希望盡量把回應都停留在這一 篇，以免污染看板太嚴重 xD 有興趣的話還是歡迎到 OOAD 或 Programming 版。 （或是 CSSE ？） ※ 引述《horngsh ()》之銘言： : ※ 引述《Favonia (小西風最乖了*^^*)》之銘言： : : 非常同意這點。我甚至可以說現在很多設計模式，都只是因為常見 : : 物件導向語言很多難用的地方。然後它們也沒有完全解決問題 orz : 我個人不同意以上的觀點, "正因為物件導向語言的1.封裝 2.繼承 3.多型 4.抽象 : 性"等, 才有辦法達成Design Pattern目的的達成, 您會發現不用物件導向語言要去 : 實作Design Pattern, 其困難度會多上許多, 比如:如果沒有了繼承和多型, 很多 : Pattern根本非常難實作。 : 以上是個人觀點, 僅供參考。 （以下大寫的常用字都是設計模式名稱） 先補充一下我原本的論點再回應。就是因為沒有 lambda 才極需要 Command, 沒有內建 reactive programming 語法所以才需要自己寫 Observer, 沒有獨立描述 介面的語法也不能方便的事後加上介面（有點饒口）所以才需要 Adapter, Bridge, Composite 等等。試著想像要是 C++0x 非常流行，很多地方都不需要 Command 了。 這就是我說「現在很多設計模式只是為了應付程式語言難用之處」的意思。 : 推 horngsh:OOA/OOD,不就是開發一點然後再分析一點再開發一點的方式嗎 07/25 07:14 : → horngsh:用OOA/OOD的方式, 會逐漸讓物件和物件間的互動和關係逐斬 07/25 07:15 : → horngsh:顯露出來, 沒有一個SA可以懂所有領域的domain knowhow,只 07/25 07:16 : → horngsh:因此想要一開始就分析設計出一個完美不用修改的SPEC是不可 07/25 07:17 : → horngsh:能的, 所以我不太認同封裝和多型會是OOPL的缺點, 但說把資 07/25 07:19 : → horngsh:料和動作綁在一起來表達封裝的意思, 確實是會限制了"封裝" 07/25 07:20 : → horngsh:的真實意涵! 07/25 07:20 首先先回應多型與封裝。多型有很多種，封裝也有很多種。不是只有和繼承 有點關係的子型態多型才叫做多型；重載也是一種多型，C++ 的樣板也是一種多 型。封裝也不是只有一種封裝。為了證明我不是在亂扯我引用一下 Wikipedia: | This mechanism is not unique to object-oriented programming. | Implementations of abstract data types, e.g. modules, offer | a similar form of encapsulation. This similarity stems from | the fact that both notions rely on the same mathematical | fundament of an existential type. @ http://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29 我想你比較的是一個多型和封裝幾乎沒有的語言，但我講的是「多型和封裝」 和主流物件導向語言（如 C++）完全不一樣的語言。我個人比較偏好其他種的多 型和封裝，不過這超出本版討論範圍了（包括什麼是 existential type）。總 之一般物件導向語言所採取的繼承與封裝有一些限制，然後設計模式可以用來補 強它們，但在我的經驗裡還是有些東西寫不出來（跟其他種的封裝和多型比較）。 當我想要寫的東西寫不出來時，理所當然的把這限制當作主流物件導向的缺點。 再來是開發程式的方式。現在有很多開發模式（例如慢慢增加測試資料來開 發的方法就叫 test-driven）都符合你所說的「一邊開發一邊修改」，但這些都 不侷限於物件導向，而且用物件導向來分析也不一定比較有利。你強調的是你的 方法有多好，我強調的是可能還有更好的方法。我想這是不矛盾的。我知道繼承 可以做到很多事情，但也有很多東西它做不到。（全部超出這個版主題） : → horngsh:還有在C/C++中的指標用法, 可以學.NET一樣,要註明為unsafe 07/25 07:22 : → horngsh:, 原波示範指標用法認為C++病了, 我倒是認為那是C語法的歷 07/25 07:24 : → horngsh:史包袱, 如果一開始C++不加入和C的相容性,C++今天不會這樣 07/25 07:25 我同意 C++ 如果不管相容性語言本身會乾淨很多，但他們就是想管 xD 如 果覺得這是缺點的話，個人建議直接跳槽到別的語言去比較快。還有我猜測原 po 重點是 C++ static 變數初始化的問題？（突然覺得有點離題了 囧） : → horngsh:,其實OO的優點還是有很多的.. 07/25 07:25 ...但是缺點也很多，尤其當你跟其他封裝方法比較時。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.112.30.39 ※ 編輯: Favonia 來自: 140.112.30.39 (07/26 01:31)
→
07/26 01:39, , 1F
你對於 DP 的概念似乎有點綁定在 OO, C++!=OO, OO!=DP
07/26 01:39, 1F
→
07/26 01:40, , 2F
GoF 的 Design pattern 對定義其實滿寬鬆的
07/26 01:40, 2F
嘗試回應一下好了。我感覺我的看法其實跟你一樣，只是我一直避免離開 本版的範圍（C++），所以文章難免充斥一堆 C++ 派的物件導向。我知道就算 限定物件導向，還有像 Smalltalk/ObjC 等等風格完全不同的語言，不過全部 都會離題 orz 我自己對設計模式下的定義是「常見問題的常見（好）解法」， 所以不同語言都有自己的設計模式。然後關於 GoF 寫的那本書我想提三點：第 一個是它的全名是： | Design Patterns: Elements of Reusable Object-Oriented Software 所以其實他們一開始就只專注在物件導向。但我強烈同意他們收集的設計 模式別的程式語言也可以用，只是別的語言的設計模式不一定會收錄進去罷了。 第二個，這本書一直推廣「物件組合比繼承好」可是好像比較少聽到有人談這 個。第三個，這本書一直強調介面，其實就是某些封裝系統的優點啊！這根本 就是在幫其他封裝系統打廣告吧 xDDD 我想引用 Wikipedia 裡面關於物件導 向發展歷史的一段話： | This is in contrast to the existing modular programming that | had been dominant for many years that focused on the function | of a module, rather than specifically the data, but equally | provided for code reuse, and self-sufficient reusable units | of programming logic, enabling collaboration through the use | of linked modules (subroutines). This more conventional | approach, which still persists, tends to consider data and | behavior separately. 我一直覺得如果真的這麼想把介面和實作，或是把資料和行為分開，那其 實可以考慮用模組或其他封裝方法。（以模組為主的程式語言也不斷在進化中， 我個人覺得一點也不輸給物件導向為主的語言。） （重新整理推文一下）
→
07/26 01:37, , 3F
為什麼 lambda 和 command pattern 是互斥的 ...
07/26 01:37, 3F
推
07/26 01:47, , 4F
這篇沒有說lambda跟command互斥，然後DP的確是建基於OO沒錯
07/26 01:47, 4F
→
07/26 01:54, , 5F
那為什麼有了 lambda 就很多地方不需要 Command?
07/26 01:54, 5F
推
07/26 02:02, , 6F
是這樣沒錯啊，但是只有lambda還不夠
07/26 02:02, 6F
→
07/26 02:03, , 7F
還需要 first-class function 以及 closure
07/26 02:03, 7F
→
07/26 02:03, , 8F
C++0x 的 lambda 我覺得根本就....很難用
07/26 02:03, 8F
沒有互斥。例如如果在 Command 裡加上 undo 就沒辦法（輕鬆乾淨的）用 lambda 做，但如果只是要延遲執行，或一次執行一大串指令，完全沒有問題。 然後 C++0x 的 lambda 有 closure 啦 xD 新標準還沒有那麼不堪。最後我個人 覺得如果要 first-class function 可能跳槽到 functional 程式語言比較快。
→
07/26 02:35, , 9F
其實甭說優點缺點, 完全是寫得爽不爽的奇魔子問題, 都
07/26 02:35, 9F
→
07/26 02:36, , 10F
那麼方便也不會有這麼多種語言了, 如果寫得熟可以把缺
07/26 02:36, 10F
→
07/26 02:37, , 11F
點當作繞點路, 甚至用其他語言的特性來做互補, 這樣作
07/26 02:37, 11F
→
07/26 02:38, , 12F
還比較實在, 戰那些都沒用
07/26 02:38, 12F
嗯我想我非常支持用多個語言一起使用（前提是合作的人也會...xD）。這 邊為了要挑戰「（某種）物件導向是寫程式唯一道路」這種說法，只好一直講 現在流行的方法並不是萬靈丹、可能有更好的方法云云 orz 在現今（某種）物 件導向程式語言統治全世界的狀況下，總覺得如果程式設計師沒有意識到有其 他選擇，那也不用談什麼互補了。至於我個人的話，我自認對 C++ 不至於非常 不熟，也不是不知道一些繞路方法... 反正大家都 Turing-complete, 沒有做 不出來的道理 xD ※ 編輯: Favonia 來自: 140.112.30.39 (07/26 08:17) ※ 編輯: Favonia 來自: 140.112.30.39 (07/26 08:34)
推
07/26 11:01, , 13F
如果function回傳一個capture區域變數的lambda會炸掉
07/26 11:01, 13F
→
07/26 11:01, , 14F
上述的動作在fp中很常見，但沒有gc的語言就很難做到
07/26 11:01, 14F
先說我還沒有把 C++0x 標準翻過一次。但就我目前非常粗淺的了解，好像 用 captured-by-copy 不會出狀況。相關標準節錄如下： | An entity is captured by copy if .... For each entity captured | by copy, an unnamed non-static data member is declared in the | closure type. .... @ C++0x (N3242) 5.1.2 / 14 | When the lambda-expression is evaluated, the entities that are | captured by copy are used to direct-initialize each corresponding | non-static data member of the resulting closure object. .... @ C++0x 5.1.2 / 21 如果我的理解沒有錯誤的話，可能還沒有太難用啦！不過如果是 captured- by-reference 我也有 90+% 的信心會導致未定義 :P ※ 編輯: Favonia 來自: 140.112.30.39 (07/26 11:41) ※ 編輯: Favonia 來自: 140.112.30.39 (07/26 22:19)
推
07/27 02:36, , 15F
這才是值得看的文章阿，感謝!!
07/27 02:36, 15F
編輯：剛才發現 Obj-C 也在看板範圍內，不過這篇文章就先這樣好了 :P ※ 編輯: Favonia 來自: 140.112.30.39 (07/28 01:52) ※ 編輯: Favonia 來自: 140.112.30.39 (09/21 08:45) ※ 編輯: Favonia 來自: 140.112.30.39 (10/09 11:56) ※ 編輯: Favonia 來自: 140.112.30.39 (10/09 13:32)
‣ 更多 Favonia 的文章
文章代碼(AID): #1EBQW4eE (C_and_CPP)
討論串 (同標題文章)
完整討論串 (本文為第 8 之 8 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共8篇)
‣ 更多 Favonia 的文章
文章代碼(AID): #1EBQW4eE (C_and_CPP)