軟體架構設計模式大全 - vikipediaaaa

KISS（保持簡單愚蠢）：

• 即使解決方案看起來很愚蠢，簡單的解決方案也比複雜的解決方案好。
• 當解決方案使用較少的繼承，較少的多型性，較少的類等時，解決方案會更好。
• 更簡單的解決方案更易於維護，即檢測和糾正缺陷更加有效。

YAGNI（您將不需要它）：

• 除非有必要，否則不要實施某些東西。
• 快速實現程式碼的最佳方法是少執行程式碼。減少錯誤的最好方法是減少程式碼。

做可能可行的最簡單的事情：

• 首先，以您認為“可能可行”的最簡單方式實現一項新功能。不要建立很多驚人的上層j架構，不要做任何花哨的事情，只需將其放入即可。甚至使用if語句。使程式碼透過新功能（以及所有功能，一如既往）的UnitTests。
• 其次，這對於規則至關重要，因此將系統重構為儘可能簡單的程式碼，包括其現在具有的所有功能。遵循OnceAndOnlyOnce規則和其他程式碼質量規則，以使系統儘可能乾淨。
• 對於IterativeDevelopment的每次增量，都應該做可能會起作用的最簡單的事情。為此，您必須至少知道兩種執行此操作的方法。這樣，您至少可以選擇較簡單的（如果不是最簡單的話）。

關注點分離 ：

• 將計算機程式分成不同的部分，以便每個部分都解決一個單獨的問題。
• 例如，應用程式的業務邏輯是一個問題，而使用者介面是另一個問題。更改使用者介面不應要求更改業務邏輯，反之亦然。
• 當關注點分開時，各個部分可以重複使用，也可以獨立開發和更新。
• 將程式功能分成儘可能少的重疊的單獨模組。

保持幹DRY：

• 程式中的每個重要功能都應該在原始碼中的一個位置實現。在類似的功能由不同的程式碼段執行的情況下，通常可以透過抽象出不同的部分將它們組合為一個程式碼，這通常是有利的。
• 複製（無意或有目的的複製）可能導致維護方面的噩夢，分解不佳以及邏輯上的矛盾。
• 修改系統的任何單個元素都不需要更改其他邏輯上不相關的元素。
• 另外，邏輯上相關的元素都可預測且一致地更改，因此保持同步。
• 僅將業務規則，長表示式，if語句，數學公式，後設資料等放在一個位置。
• 確定系統中使用的每條知識的唯一且確定的來源，然後使用該來源生成該知識的適用例項（程式碼，文件，測試等）。

為維護編碼：

• 迄今為止，維護是所有專案中最昂貴的階段。
• 始終進行這樣的編碼：就像最終維護您的程式碼的人是知道您的住所的暴力心理變態者一樣。
• 始終以這樣的方式進行編碼和註釋：如果初級的一些人發現了一些密碼，他們會很樂於閱讀和學習。

避免過早最佳化：

• 在您需要進行最佳化之前，不要進行最佳化，只有在進行效能分析之後，您才發現最佳化瓶頸。
• 經過最佳化後，可能難以閱讀並難以維護。

最小化耦合：

• 模組/元件之間的耦合是它們相互依賴的程度；耦合度越低越好。換句話說，耦合是在對程式碼單元“ A”進行未知更改後，程式碼單元“ B”將“中斷”的機率。
• 消除，最小化和減少必要關係的複雜性。
• 透過隱藏實現細節，減少了耦合。

得墨meter耳定律：

• 不要跟陌生人說話。
• 通常會緊耦合
• 它可能會透露太多實施細節
• 物件的方法只能呼叫以下方法：
  
  • 物件本身。
  • 方法的引數。
  • 在方法內建立的任何物件。
  • 物件的任何直接屬性/欄位。

組合而不是繼承

• 類之間的耦合較少。
• 使用繼承，子類可以輕鬆地進行假設並打破LSP。
• 測試LSP（可替代性）以決定何時繼承。
• 在存在“具有”（或“使用a”）關係時進行撰寫，在“是a”的情況下進行繼承。

正交性

• 正交性的基本思想是，在概念上不相關的事物不應在系統中相關。
• 它與簡單性相關。設計越正交，例外就越少。
• 這樣可以更輕鬆地學習，閱讀和編​​寫使用程式語言編寫的程式。
• 正交特徵的含義與上下文無關；關鍵引數是對稱性和一致性。

穩健性原則

• 對自己的工作要保守一些，對別人所接受的事情要開放一些
• 為了能夠發展服務，您需要確保提供商可以進行更改以支援新需求，同時最大程度地減少對現有客戶的破壞。
• 向其他計算機（或同一計算機上的其他程式）傳送命令或資料的程式碼應完全符合規範，但是，只要含義清楚，接收輸入的程式碼應接受不合格的輸入。

控制反轉：

• 控制反轉也被稱為好萊塢原則，“不要打電話給我們，我們會打電話給您”。
• 它是一種設計原理，其中計算機程式的自定義編寫部分從通用框架接收控制流。
• 控制反轉具有很強的內涵，即可重用程式碼和特定於問題的程式碼是獨立開發的，即使它們在應用程式中一起執行也是如此。
• 控制反轉用於增加程式的模組化並使其可擴充套件。
• 可以使用Factory模式，Service Locator模式，依賴注入，上下文相關的查詢，Template Method模式，Strategy模式來實現控制反轉

最大化內聚性：

• 單個模組/元件的凝聚力是其職責形成有意義的單元的程度；凝聚力越高越好。

里斯科夫換人原則：

• LSP是關於物件的預期行為的。
• 程式中的物件應該可以用其子型別的例項替換，而不會改變該程式的正確性。

開/關原則：

• 軟體實體（例如類）應為擴充套件而開放，但為修改而封閉。即，這樣的實體可以允許在不更改其原始碼的情況下修改其行為。
• 透過最小化對現有程式碼的更改來提高可維護性和穩定性。
• 編寫可以擴充套件的類（與可以修改的類相反）。
• 僅暴露需要改變的運動部件，隱藏其他所有部件。

單一責任原則：

• 每個班級應負一個單一的責任，而該責任應由班級完全封裝。責任可以定義為變更的原因，因此，一個類或模組應該只有一個變更原因。
• 可維護性：僅應在一個模組或一個類中進行更改。

隱藏實施細節：

• 軟體模組透過提供介面來隱藏資訊（即實現細節），並且不會洩漏任何不必要的資訊。
• 當實現更改時，客戶端使用的介面不必更改。
• 最小化類和成員的可訪問性。
• 不要公開公開會員資料。
• 避免將私有實現細節放入類的介面中。
• 減少耦合以隱藏更多實現細節。

捲曲定律：

• 捲曲定律是關於為任何特定程式碼段選擇一個明確定義的目標：做一件事情。

封裝變化了什麼：

• 好的設計可以識別最有可能發生變化的熱點，並將其封裝在API之後。然後，當發生預期的更改時，修改將保留在本地。
• 最小化發生變更時所需的修改
• 封裝了API背後的概念
• 可能將變化的概念分成自己的模組

介面隔離原理：

• 將胖介面減少為多個更小，更具體的客戶端特定介面。介面應該比實現它的程式碼更依賴於呼叫它的程式碼。
• 如果一個類實現了不需要的方法，則呼叫者需要了解該類的方法實現。例如，如果一個類實現一個方法而僅僅丟擲一個方法，則呼叫者將需要知道實際上不應該呼叫此方法。
• 避免胖介面。類永遠不必實現違反單一職責原則的方法。

童子軍規則：

• 美國的童子軍有一個簡單的規則可以應用到我們的職業中：“讓營地比您發現的要乾淨”。童子軍規則指出，我們應始終將程式碼保留得比發現的乾淨。
• 在更改現有程式碼庫時，程式碼質量趨於下降，從而增加了技術負擔。遵循boyscout規則，每次提交時都應注意質量。不論大小，技術債務都會受到持續重構的抵制。
• 每次提交時，請確保它不會降低程式碼庫的質量。
• 每當有人看到一些不盡如人意的程式碼時，他們都應該趁此機會在此位置進行修復。

命令查詢分隔：

• 命令查詢分離原則指出，每種方法都應該是執行操作的命令，或者是將資料返回給呼叫方的查詢，但不能兩者都是。提出問題不應修改答案。
• 有了這個原則，程式設計師可以更加自信地進行編碼。由於查詢方法不會改變狀態，因此可以在任何地方以任何順序使用。使用命令時，必須格外小心。
• 透過將方法清楚地分為查詢和命令，程式設計師可以放心地編寫程式碼，而無需瞭解每種方法的實現細節。
• 將每種方法實現為查詢或命令
• 將命名約定應用於方法名稱，這暗示該方法是查詢還是命令