2010-01-13 27 views
5

我應該完全熟悉的設計模式是什麼?什麼是一個簡單的例子,每個可以用於?Web開發中的設計模式有多重要?

我是一個Web開發人員(我使用Django,並且熟悉邏輯的分離),但我在一個桌面應用程序內的公司工作。他們總是在談論單身,我忘記了...但它讓我沒有任何線索!

+0

社區wiki .... – jldupont 2010-01-13 21:17:55

+0

當然,社區wiki。 – TIMEX 2010-01-13 21:18:38

+0

只是讓自己最相關的書,並通過這一切。 – 2010-01-13 21:29:10

回答

10

忘記辛格爾頓。這很混亂,很少需要。

瞭解國家戰略命令。他們一直在使用。

狀態是任何有依賴於對象的狀態邏輯。總之,通過可能會更好地完成每個if語句。認真。太多if語句是一種代碼味道,並且表明有狀態處理遍佈整個地方。

策略爲任何「插件」或「膨脹」或「選項」的處理。

命令爲任何擴展的(和組合的)行動組。備份,恢復。表格刪除,創建,索引,填充。驗證,加載,總結,報告。任何可以以不同方式,不同順序等組合在一起的命令式事物都應該使用正式的設計來完成。

+0

+1爲戰略模式。我學到的最有用的東西,設計模式明智。 – GSto 2010-01-13 21:37:25

+0

-1表示'忘記'單身人士。是的,它被過度使用,大多數情況下傾向於像一個全球靜態,這是可怕的,但需要知道它是什麼,它有時是必要的。當然,我不會建議任何人忽視它,或者不會對這種廣泛使用的模式不熟悉。如果沒有其他的理由,而不是在設計會議上能夠有效論證爲什麼我們絕對不應該使用它,就必須熟悉它。 – 2010-01-14 19:47:24

+0

@DaveSims我同意你的意見。我最喜歡的例子是數據庫連接對象。如果我們必須將它傳遞給系統中的每個方法,我們都會堅持下去。 – dotslash 2016-01-16 06:44:41

11

MVPMVC

Model View PresenterModel View Controller

更多2009建築的圖案,但neverless,它們的設計模式的組合。

+5

非常大膽的說法。我發現很多場景MVC可能不合適或者毫無意義的開銷。 – 2010-01-13 21:21:00

+1

我不同意。對於可測試性以及ASP.NET MVC等框架而言,不遵循這些模式可能會更痛苦。 – Finglas 2010-01-13 21:23:00

+3

雖然「沒有Web應用程序應該沒有它們」可能太過於大膽,但我會爭辯說「沒有Web應用程序開發人員應該沒有它們的知識」。 – 2010-01-13 21:24:37

2

老實說,模式很重要,但知道何時使用它們同樣重要。永遠不會有任何答案,這是你需要爲自己感覺的東西。與之鬥爭的人絕對應該總是使用它們,或者始終不使用它們是不正確的。設計模式是一種工具。我建議你在亞馬遜網站上找一本你正在編寫的語言書籍,專門處理設計模式。我知道有一本爲Ruby on Rails編寫的書,雖然我不記得名字,但還有一本名爲Head First Design Patterns的Java,以及由Bob和Micah Martin編寫的非常棒的C#。請閱讀適用於您最熟悉的語言的那些語言。即使你沒有使用所有的模式,也很好理解它們是如何工作的,以及它們何時有用。

0

MVVM是我見過的用於Silverlight的新版本。這有點多,但看起來很有效。

+1

你是不是指MVVM或Model View ViewModel?如果不是這對我來說是新的。 – Finglas 2010-01-13 21:32:10

1

瞭解設計模式不會有太大的使用,直到你知道他們爲什麼對給定問題的最佳策略。從一開始就學習設計模式可能很好,除非你錯過了所有「錯誤」的方法來解決這個問題,這反過來又意味着你可能會錯過使用給定模式的時候以及何時不使用它。

唯一不如誰堅持自己的老辦法也懶得學習的正確方法的人,是誰學習的正確方法和不打擾學習爲什麼這樣是正確的人。他們繼續將它應用於不應用的東西,因爲它們只是不知道更好。

所以我的觀點是,如果你在Web開發是新的,不要在設計模式炒作過於趕上了(儘管這是一個很好的炒作)。通過自己做東西來學習。當你達到一定的水平時,閱讀設計模式,看看它們可以應用到哪裏,使代碼更好。

這是你如何正確地學習它們。不像在你走路之前被迫跑步。

1

對於Web應用程序,至少在基本層次上了解中描述的模式對於我來說,企業應用程序體系結構的模式已被證明是有價值的。四人幫也值得了解。

但我認爲,你根本不需要的模式博聞強記上手。粗略的理解將幫助您瞭解當您的想法/業務問題與代碼之間發生摩擦時,應該看哪裏。我有幾次週末旅行,這讓我可以全面瀏覽這兩本書,但我仍然發現模式部分的詳細信息作爲參考比作爲背景知識更有用。

讀只是「第1部分」 GoF的或POEAA的部分將有助於遠遠超過學習深入三四模式,因爲你知道,當你遇到它們描述的問題看。你可以查看他們在線描述的大部分模式的細節。

,我直接或間接使用,常常不自覺,在web開發GOF模式,包括:觀察,指揮,綜合,國家,戰略。除了作爲日誌和服務定位器/依賴注入工具的客戶端,我通常不使用Singleton。我經常無意識地或偶然地使用PoEAA模式作爲我正在使用的數據訪問策略或Web框架的一部分,它們是活動記錄,應用程序控制器,數據映射器,域模型,網關,延遲加載,圖層超類型,頁面控制器,模板視圖和值對象。這並非詳盡無遺;這些只是幾個想到的。

多數那些可能更有效地與一個固執己見的Web開發框架出發,像Rails的,Django的,或城堡單軌,比抽象的教訓。畢竟,模式是從成千上萬的成功應用程序開發經驗中識別出來的,並沒有被髮明出來,然後因爲它們聽起來很聰明而被粘在一起。

很容易因爲在一種或兩種模式上獲得的好於表面的知識而過分興奮,然後看到「緊隨其後的每個問題」的「唯一指甲」,並試圖將不合適的模式敲入解決方案因爲你瞭解它是如何工作的。

所以,學習模式,是的;對所有常用的動機做一個膚淺的概述,但是不要覺得你必須等到編寫嚴肅的代碼,直到你理解了它們的任意列表爲止。