在本書的第二部分重新審視了一下三種基本的程式設計正規化：結構化程式設計、物件導向的程式設計與函式式程式設計，並提出了乙個重要觀點：
從2023年圖靈為電子計算機寫下第一行**到現在，軟體的基本規則一直沒有變過。電腦程式的最基本構件始終是順序（執行）、選擇、遞迴和間接應用（indirection）。程式設計正規化並沒有在增加我們的能力，反而限制了某些我們寫**的方式。簡單來說，程式設計正規化就是告訴我們不要做什麼。
2023年dijkstra提出結構化程式設計思想的時候指出「goto語句是有害的」，這之後出現的很多程式語言限制或徹底取消了goto語句。結構化程式設計對控制的直接轉移進行了限制。
dijkstra曾經試圖將數學中的形式證明方法引入計算機軟體領域，從簡單的「公理」出發，通過規範的形式邏輯推導，證明電腦程式的正確性。當然我們現在知道他的這個「理想」失敗了。至今還沒有方法可以「證明」程式的正確性。
但是，程式是「可測試的」。從這一點來說，軟體更接近科學而不是數學。「可測試的」對應了科學中的「可證偽的」。正是建立「可證偽的」（可測試的）程式單元的能力使得結構化程式設計到今天依然非常有價值。在架構層次上，功能分解依然是最佳實踐之一。
軟體架構致力於定義易於測試的模組、元件與服務。
作者首先分析了傳統上對oop的特徵的總結：封裝、繼承和多型，指出這三個特徵並不能確切描述oo的特性。在沒有oop以前，c語言就可以實現將資料和函式封裝為乙個模組，隱藏私有資料的同時對外暴露公開的函式。同樣的，在oop以前，c語言也可以實現繼承。當然oop使得實現繼承更方便了。
在沒有oop以前，通過函式指標一樣可以實現多型。但是oop使得多型的實現更加安全和方便。使用函式指標時需要遵循一系列人為的約定或慣用法，如果在這方面稍有疏漏就可能產生非常難以跟蹤與消除的錯誤。而oop提供的多型機制消除了這樣的風險。
雖然同樣都沒有提供全新的特性，只是使原有的程式設計方法更安全和方便，但是作者顯然認為多型比繼承更有價值，至少在架構的層面的如此，因為正是多型使我們可以做到「依賴倒置」（dependency inversion）：
> oo語言提供了安全而方便的多型機制的事實意味著任何源**依賴關係——無論在什麼地方——都可以被顛倒過來。
在本書後面的很大篇幅都在將「整潔」的軟體架構中應該有怎樣的元件依賴關係，而要實現理想中的依賴關係，沒有「依賴倒置」是不可能做到的。
最後總結，什麼是oo？對於軟體架構來說，oo就是通過使用多型，完全地控制系統中所有源**依賴關係的能力。
函式式程式設計的概念可以追溯到二十世紀三十年代alonzo church發明的lambda-運算元。但是函式式程式設計之所以最近又「火」了起來，是因為函式式程式設計比命令式程式設計需要多得多的記憶體和處理能力。這只有在儲存器和計算能力非常廉價的今天才有可能實現。
函式式程式設計限制了我們對變數的使用。純粹的函式式程式設計中，變數都是「不可變」的（immutable），實際上等於取消了「變數」。
競爭條件(race conditions)、死鎖、併發更新，這些併發程式中常見的難題都是由於可變的變數引起的。函式式程式設計通過強制immutable，也就消除了這些問題。
純粹的函式式程式設計需要無限的內容和處理能力，並且當程式需要與外部裝置互動式，幾乎不可能避免處理可變狀態。這些問題可以通過一些妥協手段。
乙個是對「可變性」的隔離。將程式分為不可變狀態的元件和可變狀態的元件。前者依賴後者，程式狀態再儲存在「transactional memory」中，通過一些不可併發的原子操作進行處理。
另乙個是只儲存事務、不儲存狀態，稱之為event sourcing。當需要查詢狀態時便重新計算一下所有事務，得出最新狀態。這樣就把資料的crud操作簡化成只有「c(reate) r(ead)」操作了。網上關於event sourcing的內容很多，這也是ddd (domain driven design)中的重要內容，在此不贅述。
讀書筆記 《架構整潔之道》（更新中 ）
首先，推薦下新棟book製作的思維導圖，基本上涵蓋了本書的核心要點。個人認為，讀書讀到最後其實是乙個不斷把書讀薄的過程，同時又是乙個不斷把書越讀越厚的過程，前者側重於提煉書籍的核心要點並內化吸收，後者側重於吸收書籍的思想養分後不斷豐富。有時候，讀一本書，總想在最後提煉出結論性的幾句話已表明自己真正讀...
《架構整潔之道》閱讀筆記03
接著上一次的 架構整潔之道 閱讀筆記02繼續寫最後一篇 1.軟體開發技術發展的歷史 就是乙個如何想法設法方便地增加外掛程式，從而構建乙個可擴充套件 可維護的系統架構的故事。2.系統的核心業務邏輯必須和其他元件隔離，保持獨立，其他元件要麼可以去掉的，要麼有多種實現的。業務邏輯是乙個系統存在的意義，屬於...
《架構整潔之道》閱讀筆記02
軟體系統可以通過行為和架構兩個維度來實現實際價值 7.1行為價值 包括需求的實現，以及可用性保障 效能 穩定性 是最直觀的價值 7.2架構價值 軟體系統必須靈活，必須容易被修改 7.3架構價值是否是必須要有的？如果業務是明確的 穩定的，架構的價值就可以忽略不計 但業務通常是不明確的 飛速發展的，這時...