程式設計師修煉之道6

《程式設計師修煉之道》第五章內容概述 ：
解耦與得墨忒耳法則：倡導把程式碼組織成最小單位即模組，並限制它們之間的互動，以減少耦合。因為物件間直接的橫貫關係可能導致依賴關係的組合爆炸，一個模組的改動會影響到許多無關模組。函式的得墨忒耳法則規定了物件呼叫方法的限制，即只能呼叫自身、傳入引數、建立物件以及直接持有的元件物件的方法。
源程式設計：介紹了後設資料是關於資料的資料，在執行時而不是編譯時被訪問和使用。透過將抽象放進程式碼，細節放進後設資料，可使系統變得高度可配置，如螢幕顏色、提示文字等應作為配置項而非硬編碼到專案中，要以宣告方式思考，建立高度靈活和可適應的程式。
時間耦合：指出時間耦合涉及併發和次序兩個重要方面。軟體設計應容許併發，並解除時間次序上的依賴，可使用 UML 活動圖進行工作流分析以改善併發性。在架構設計時，建議使用服務而非元件，飢餓的消費者模型是一種有效的負載平衡途徑。
他只是檢視：闡述了將程式劃分成不同模組，每個模組具有單一明確責任的重要性。模組間通訊可採用釋出 / 訂閱模式，即 Observer 模式，訂閱者向釋出者註冊後接收事件通知；以及 Model-View-Controller 架構模型，它能分離模型與表示模型的 GUI，降低資料和檢視間的相互影響 。
黑板：將黑板抽象為一種處理事件的模型，不同於傳統工作流需考慮各種複雜狀況和順序，黑板系統只管基礎的寫入、讀取、查詢、通知等功能，任意符合條件的事件都可進入，這也是一種解耦形式，不同線索之間可獨立進行，共同幫助解決問題。
《程式設計師修煉之道》第五章讀後感
對解耦重要性的深刻理解：透過閱讀，我深切認識到解耦在軟體開發中的關鍵作用。在實際專案中，隨著功能的不斷增加和業務邏輯的日益複雜，如果程式碼之間的耦合度過高，一個小的改動可能會引發一系列意想不到的問題，導致整個系統的維護成本大幅上升。就像書中所講，解耦能夠使各個模組相對獨立地發展和變化，當某個模組需要進行功能升級或修復缺陷時，不會對其他無關模組產生過多的影響，從而提高了系統的可維護性和可擴充套件性。這讓我在今後的程式設計實踐中，會更加註重程式碼的組織結構，儘量降低模組之間的耦合度，使系統更加靈活和健壯.
元程式設計的啟示：元程式設計的理念為我開啟了一扇新的思維之門。它讓我意識到，在編寫程式碼時，不僅要關注當前的功能實現，還要考慮到未來可能的變化和配置需求。將一些可變的因素，如介面顯示的文字、顏色等配置資訊，從程式碼中分離出來，透過後設資料的方式進行管理，可以使程式更加易於配置和適應不同的執行環境。這種以宣告方式思考的方法，能夠讓程式碼更加簡潔和靈活，減少因需求變更而對程式碼進行大量修改的情況，提高了程式碼的複用性和可維護性.
時間耦合的思考：時間耦合的概念讓我對軟體系統中的時間因素有了更深入的思考。在多執行緒和分散式系統日益普及的今天，併發和次序問題是我們必須要面對的挑戰。書中提到的解除時間次序上的依賴以及使用 UML 活動圖進行工作流分析等方法，為我在處理這類問題時提供了很好的思路和工具。在設計系統架構時，要充分考慮到各個元件之間的時間關係，儘量避免因為時間上的先後順序而導致的緊耦合，從而提高系統的併發性和效能.
模組通訊方式的學習：他只是檢視中介紹的釋出 / 訂閱模式和 Model-View-Controller 架構模型，讓我對模組之間的通訊和互動有了更清晰的認識。釋出 / 訂閱模式能夠實現模組之間的鬆散耦合，使得訊息的傳送者和接收者之間不需要直接依賴，提高了系統的靈活性和可擴充套件性。而 MVC 架構則是一種經典的設計模式，將資料、檢視和控制邏輯分離，使得各個部分可以獨立地進行開發、測試和維護，降低了系統的複雜度。在今後的專案中，我會根據具體的業務需求，合理地選擇和應用這些模組通訊方式，以提高系統的架構質量.
黑板模型的借鑑意義：黑板模型作為一種特殊的解耦形式，為處理複雜的事件和資料提供了一種新的思路。它類似於一個共享的資訊空間，各個模組可以在其中自由地寫入和讀取資訊，而不需要關心其他模組的具體實現和處理邏輯。這種方式可以有效地降低模組之間的耦合度，提高系統的靈活性和可擴充套件性。在一些涉及到多工協作、資料共享和複雜業務流程的專案中，黑板模型可以作為一種很好的解決方案，幫助我們更好地組織和管理程式碼.