課堂

1.1 應用架構 本課程專為初學者設計，因為您不會長時間設計嚴肅應用程序的架構。但別擔心，好的架構是例外而不是規則。在構建應用程序之前選擇正確的應用程序架構是非常困難的。 大型服務器應用程序的流行架構示例： 分層架構（Layered Architecture）。 分層架構。 面向服務的體系結構 (SOA)。 微服務架構（Microservice Architecture）。 他們每個人都有其優點和缺點。但是研究它們不會給你任何東西。架構是對“如何組織系統內數千個對象的交互”這

三層架構簡介 三層架構是互聯網上最常見的交互架構。當兩層服務器部分被分為邏輯層和數據層兩部分時，它就出現了。 它看起來像這樣： 客戶端層是負責用戶交互的“分佈式應用程序”的一部分。該層不應包含業務邏輯，也不應存儲關鍵數據。此外，它不應直接與數據庫層交互，而只能通過業務邏輯層進行交互。 但是，這裡仍然有一些邏輯。首先，這是通過界面與用戶交互，驗證他輸入的數據，使用本地文件。這還包括使用服務器時與用戶授權和數據加密相關的所有內容。 其次，是簡單的業務邏輯。例如，如果一個在線商店發

MVC架構介紹 每個程序員都知道的最流行的應用程序架構是MVC。MVC 代表模型-視圖-控制器。 這與其說是應用程序的架構，不如說是應用程序組件的架構，但我們稍後會回到這個細微差別。什麼是 MVC？ MVC 是一種將應用程序數據和控制邏輯分離為三個獨立組件（模型、視圖和控制器）的方案，以便每個組件都可以獨立修改。 模型（Model）通過改變其狀態來提供數據並響應控制器命令。 視圖負責向用戶顯示模型數據以響應模型更改。 控制器（Controller）解釋用戶的動作，通知模型需要

效率 有經驗的程序員可以很容易地分辨出架構的好壞，但如果被要求用幾句話來描述它，他們不太可能做到。好的架構沒有單一的標準，也沒有單一的定義。 然而，如果你仔細想想，你可以寫出一些好的架構應該滿足的標準。一個好的架構首先是一個邏輯架構，它可以讓程序的開發和維護過程更簡單、更高效。 當程序具有良好的體系結構時，總是很容易理解它是如何工作的以及在何處編寫代碼。一個結構良好的程序更容易更改、測試、調試和開發。聰明人制定了以下優秀架構的標準： 效率; 靈活性; 可擴展性； 可擴展性；

不良設計的標準 生活很簡單：通常，要聰明，你只需要不做傻事。這也適用於軟件開發：在大多數情況下，要想把一件事做好，你只需要不把它做得不好。 大多數程序員都有過設計糟糕的系統部分的經驗。但更可悲的是，你們中的大多數人都會有悲傷的經歷，意識到自己是這樣一個系統的作者。我們想要最好的，但結果一如既往。 大多數開發人員並不渴望糟糕的架構，對於許多系統來說，他們開始說它的架構很糟糕。為什麼會這樣？架構設計是從一開始就不好，還是隨著時間的推移變得不好？ 這個問題的根源是缺乏“壞”設計的定

6.1 分解 儘管標準多種多樣，但大型系統開發的主要任務是降低系統的複雜性。為了降低複雜性，除了分成幾部分之外什麼也沒有發明。 有時，為了簡單起見，這被稱為“分而治之”原則，但是，從軟件架構師的角度來看，我們談論的是層次分解。 一個複雜的系統必須由少量較簡單的子系統構建而成，每個子系統又由較小的部分構建，依此類推，直到最小的部分足夠簡單，可以直接理解和創建。 好消息是這個解決方案不僅是唯一已知的，而且是通用的。除了降低複雜性之外，它還通過複製關鍵部分同時提供系統靈活性、良好的

層次分解 您永遠不應該立即開始為您的應用程序編寫類。首先需要對其進行設計。設計應該以深思熟慮的架構結束。要獲得此架構，您需要始終如一地分解系統。 分解必須分層進行——首先，系統被分成大的功能模塊/子系統，以最一般的形式描述其操作。然後對生成的模塊進行更詳細的分析，並將其劃分為子模塊或對象。 在選擇對象之前，將系統分成基本的語義塊，至少在心理上是這樣。在小型應用程序中，這通常很容易做到：幾個級別的層次結構就足夠了，因為系統首先分為子系統/包，而包又分為類。 這個想法並不像看起來

8.1 分解就是一切 為了清楚起見，一張來自一篇好文章“面向對象系統的解耦”的圖片說明了將要討論的要點。 您還認為設計應用程序架構很容易嗎？ 8.2 接口，實現隱藏 降低系統耦合度的主要原則是OOP的原則和其背後的封裝+抽象+多態的原則。 因此： 模塊應該是彼此的“黑盒子”（封裝）。這意味著一個模塊不應該“爬升”到另一個模塊並且不知道它的內部結構。一個子系統中的對像不應該直接訪問另一個子系統中的對象。 模塊/子系統應該僅通過接口（即不依賴於實現細節的抽象）相互交互。因此，每個

9.1 依賴倒置 請記住，我們曾經說過，在服務器應用程序中，您不能只通過創建流new Thread().start()？只有容器應該創建線程。我們現在將進一步發展這個想法。 所有對像也應該只由容器創建。當然，我們不是在談論所有對象，而是在談論所謂的業務對象。它們通常也被稱為垃圾箱。這種方法的支柱源於 SOLID 的第五條原則，該原則要求擺脫類並轉向接口： 頂級模塊不應該依賴於低級模塊。那些和其他人都應該依賴於抽象。 抽像不應依賴於細節。實現必須依賴於抽象。 模塊不應該包含對特

用消息傳遞代替直接依賴 有時一個模塊只需要通知其他人它發生了一些事件/變化，而這些信息以後發生什麼並不重要。 在這種情況下，模塊之間根本不需要“相互了解”，即包含直接鏈接並直接交互，但只需交換消息（messages）或事件（events）就足夠了。 有時似乎通過消息傳遞的模塊通信比直接依賴要弱得多。事實上，因為沒有調用方法，所以沒有關於類的信息。但這只不過是一種錯覺。 邏輯開始與消息類型、它們的參數和傳輸的數據相關聯，而不是方法名稱。這些模塊的連接性被抹黑了。 它曾經是這樣的