設計模式 - 建築宇航員

Question

也許我的問題是，在本質上這一個類似的：Do you use design patterns?

我寫的程序是小50-75日K線的方案大多采用Windows Forms和ASP.NET。這些程序是圖形用戶界面密集型的，可以設計和佈局各種圖形和圖形處理。

我認爲自己擅長OOP並且在平衡OOP和傳統程序方法以創建可維護代碼方面做得很好。

當我考慮設計模式時，問題就出現了。鏈接到線程有一個有趣的評論，可以使用設計模式，但不是有意的。當我想故意使用設計模式（在我的程序設計中）時，感覺就像我要超越需要的那樣，我處於「architecture astronaut」的領域，所以我回歸到我的傳統方法和一切順利進行（即通常）。

以MVC模式爲例。如果我想使用Windows Forms或ASP.NET（Visual Studio 2005）來實現這種模式，那麼我必須編寫一個「框架」，編寫框架似乎比應用程序的大小更加麻煩。

也許我的應用程序太小，以至於無法使用這些模式中的一部分。 也許我只是不太瞭解模式或需要更多地研究它們。

有沒有其他人體驗過這種「架構宇航員」的感覺？

你如何去故意使用設計模式而不去「過度」？

Answer 1

當談到這種性質的小型應用程序，我一般更擔心anti-patterns比我做的設計模式。也就是說，它實際上是同一個硬幣的兩面：對於我來說，設計模式的力量正在熟悉它們，以便認識到我想到的任何解決方案的不太明顯的利弊。我很少從事實際完全實現完整設計模式的工作（除非我真的需要所有功能）;然而，我通過認識到自己正在經歷的路徑並觀察該解決方案的常見缺陷或缺點，經常爲未來的重新工作節省了很多，然後我可以檢查未來的用途，看看它是否會出現對我來說是否有關係。因此，設計模式的強大之處在於，您可以輕鬆地預測當前解決方案對未來潛在需求的影響，而無需擔心您可能會遺漏某些您沒有考慮的不太明顯的警告或特殊情況。 '

Answer 2

MVC本身並不要求你編寫任何框架。它僅僅意味着你將視圖，控制器和模型代碼分開。我使用MVC（或MVP）來處理簡單的移動應用程序，因爲我發現控件的分離在編寫測試時非常有利（更不用說改變UI時）。

我的猜測是你現在不做大量的單元測試或集成測試，所以它並不是很明顯，這個分類有助於提高代碼的質量和可讀性。

我強烈建議你閱讀Fowler's coverage of UI architectures。

Answer 3

對於我來說，這取決於：

• 的應用程序的大小，
• 的設計模式中使用，
• 我在建築投資前期的時間量。

在一個小應用程序中，我很少使用任何設計模式，除非它們在擴展或維護應用程序的範圍內具有很高的投資回報率，否則不會自然流動。

Answer 4

您正在一個大型公司爲您設置模式的環境中工作，我認爲這解釋了您的感受。你可能是對的。我們這些在開放環境中使用FOSS語言來解決更廣泛的問題的選擇是無窮無盡的，閱讀設計模式有助於我們做出有關架構的明智決策。通常這意味着選擇正確的庫。您爲您工作的狹隘領域做出的選擇已經爲您做好了。

Answer 5

的模式就在那裏爲一般性問題抽象的解決方案。如果有人知道這些模式，那麼他們更有可能更快地應用已知的解決方案，而不是圍繞着思考，「我想知道如何做這個工作。」

關於框架：如果你在一個團隊中不止一人（這聽起來並不像你根據你的項目規模較小）的工作，框架可以幫助讓每個人都做的事情一樣這對於可維護性的團隊努力以及迅速讓新人適應速度很重要。

Answer 6

恕我直言，一個需要有：

1. 正反不同的設計 模式&缺點，你可以用在你的應用程序是專門做，使
2. 清晰的良好理解 確定該模式的優點被用於您的優勢。

以MVC模式爲例。如果 我想要實現使用 的WinForms或ASP.NET（VS 2005），那麼我 必須寫一個「框架」，並 寫作框架，這種模式似乎更 麻煩比它的價值的應用程序的大小 。

請問您的Web應用程序需要有效的SEO？在ASP.NET中實現的MVC模式在這方面可能會有所幫助。以SO URL爲例。它們對於搜索引擎的優化非常好，主要是因爲ASP.NET的MVC模式實現支持它並且已經在SO設計/開發中得到了有效的使用。

Answer 7

'你如何去故意使用設計模式而不去「過度？」'

簡單。

1. 請勿混淆MVC框架開發工作與模式。

2. 認識到你做的每一件事情之前已經完成（由你或其他人）。

3. 當你重複的東西 - 任何東西 - 您遵循的模式。

4. 當您爲任何事物重複設計 - 無論多小 - 您都遵循設計模式。

5. 當您發現自己重複某件事情時，請爲您正在重複的事件指定一個名稱。看，你已經發現並命名你的第一個設計模式。無論多小。

6. 當您命名設計模式時，您可以考慮何時使用它，爲什麼要使用它，它解決了什麼以及使用它的後果是什麼。無論多小。

7. 每一件涉及「重複設計元素」的學習都是設計模式。無論多小。

每個循環。每個if語句。每個對話框。每個文件都打開。這些都是設計模式。

大部分都是該語言的一部分，並且具有明顯的語言特定名稱。 「IF」，「OPEN」等。

某些設計模式比單個語句大，但小於整個MVC框架。那些是有趣的。瞭解這些。買一本書。閱讀。 MVC不會出現在大多數設計模式書籍中，因爲 - 好 - 它太複雜，太難以應用。

不要以MVC開頭。以其他任何方式開始。

Answer 8

幾乎任何適當的設計模式，應用時，應導致簡化。如果你讓事情變得更加複雜，那麼你可能會針對你的具體問題向錯誤的方向發展。

Answer 9

簡單的問題通常需要簡單的解決方案，儘管一些難題很簡單。另一方面，複雜的問題可以通過有組織的方式或通過骯髒的意大利麪代碼來解決。許多人試圖組織軟件設計，並且出現了一些「模式」並得到了名稱。

當您將設計意圖傳達給其他人時，我認爲模式是非常有用的詞彙，但它並不是您將其推入設計的東西。當您根據需要將代碼解耦合時，您可以根據需要應用模式。例如，當您發現自己製作非常複雜的構造函數時，將其放入構建器模式中。

將業務邏輯中的數據層和UI層從我的業務邏輯中分離出來是你應該做的一件好事。同樣，低耦合，DRY和可維護代碼應該是目標，而不是模式。

Answer 10

「建築宇航員」是那些花費大量時間討論設計的人，但實際上並沒有發生任何事情。

我喜歡書中「模式重構」中介紹的設計模式的方法。在這裏，模式不是我們在前期投資的東西，而是我們在減少代碼複雜度之後才做的事情。因爲這種方法需要功能代碼才能開始，並且基於哪些代碼可以更容易地擴展該代碼以滿足特定需求來選擇重構，所以其重點在於非常多的結果。

Answer 11

不要忘記溝通 - 衆所周知的設計模式可以讓你用幾句話來交流一些複雜的東西。當你說「使用觀察者模式發送通知」時，每個人都知道你的意思。

Answer 12

極少數項目需要或超架構的好處。大多數以這種方式開始的項目從未完成。許多確實很難延伸或維持的人（儘管他們有相反的說法）。請記住語言和技術的發展速度。當你完成一個非常大的項目時，今天最新最酷的東西可能已經過時了。模式很有趣，可以讓你瞭解如何優雅地解決問題，但大多數時候，在現實世界中，沒有優雅的解決方案。我曾經在那裏工作過的地方都有一位超級明星宇航員，在編寫垃圾代碼時我會留下無盡的行話給每個人留下深刻的印象，以後我將不得不修復這些代碼。最終的結果是最重要的。您的公司需要一個工作應用程序，而不是一個正在進行的無盡工作，即使他們自己沒有意識到。