Day06 抽象層 (abstraction)

• 什麼是抽象層 (abstraction) ？
• 幾種不同的抽象層
• 抽象層的模組型定義導致的推論

什麼是抽象層？

非正式的定義：抽象層是我們使用間接層建構出來的概念工具。

模組型的定義：大部分的軟體抽象層採用模組 (module) 的型式，模組可以分解成三部分：模型 (model) 、介面 (interface)、外界的環境 (environment) 。

• 模型是一整組的資料結構與函數
• 介面介於模型與環境之間
• 環境則是所有其它的東西：包含其它的軟體元件、使用者、和該模組存在的世界

模型反映了外界環境的某些特定層面，可以讓我們的注意力聚焦，讓我們可以對本來過度複雜的事物進行思考、推論。每一件沒有直接被模型反映的事，代表的是一個假設 (assumption) ，這個假設意謂著這個刻意被遺漏之層面通常是固定的事實、或是並不重要。如果模型本身的特性也可以表現不合邏輯的狀態，(即該狀態無法在真實世界找到對應)，該模型必須強加一些守恆性 (invariants) 來排除這些狀態。

幾種不同的抽象層

當思考到，軟體的抽象層，其實是對真實世界的建模時，我們很自然也會想到，物理學不也是如此嗎？物理學也是一種對真實世界的建模。然而，物理學的抽象層與軟體的抽象層還是有許多本質上的不同。數學的抽象層又更極端、根本不需要考慮外界環境。

抽象層的模組型定義之推論

我們的目標是要做出好的模組。要做出好的模組，我們至少要能評斷是否一個模組是有用的。儘管有了抽象層的模組型定義，還是不能有效地回答『是否一個模組有用』或是說『如何改進一個模組』這些問題，我們還是可以得出許多的推論。

• 抽象化的本質是忽略不重要的細節、是把一些有相似性質卻不同的事物視為是相同的。
• 模組反應了我們對模組所處環境的認知。

如果一顆樹掉了一片葉子，我們還是認為它是同一顆樹。這是因為我們內心中對樹的認知模型，並不會列舉每一片葉子。然而，模型可以忽略哪些細節，要視情境而定。如果我們製做販賣球賽的門票的軟體、球員是否受傷的細節狀態通常會被軟體忽略：『一個隊伍即使有球員受傷還是視為是同一隊。』另一方面，如果我們要設計的軟體，是要預測球賽的勝負，那球員受傷的隊伍，就不再視為跟原來一樣。

• 只有當模組的假設是完備且合理時，模組才會有用/好用。
• 要瞭解一個模組的假設，我們必須先了解模組的模型。

以 SQL 資料庫為例子，這個模組的假設之一，是沒有惡意的使用者會做 SQL 注入攻擊。這個假設在企業內部系統可以是真的、然而在企業外部則通常不是。也因此，假設的完備性很重要。我們評斷模組的假設時，我們要充分考慮我們的環境 (environment)，最好要同時考慮現在還有將來的環境。

一個模組的假設 (assumptions) 與 模型 (model) 常常有對偶 (dual) 關系，瞭解了其中一個，就可以推論出另一個。如果我們沒有充分瞭解我們使用的模組，我們也就不能得知『何時這個模組依賴的假設會失效？』充分地瞭解使用的軟體模組在哪些情況會失敗，比起盲目地使用它們並且祈禱成功來得務實的多。

我們要建構軟體時，使用模組的信心，應該要來自於對模組的充分瞭解。沒有充分瞭解就使用模組，這塊模組本身就變成了一種『神喻』，我們只能選擇相信或是不相信。使用了自己不瞭解的軟體模組，也許還是可以把東西做出來，然而這只是持有 (possess)，而非瞭解 (understand)。持有而不瞭解就是菜鳥常幹的事。

• 模組會管用，通常是因為它們夠小。

模組隨著時間的流逝，有時候會增加新的功能 (features)，有時會修復臭蟲 (bugs) ，無論哪一項都是讓模組變大、反應更多外在環境的現實，並且讓它更難被理解。模組必須被人理解才能產生價值。

要控制模組的大小、最重要的是要控制它成長的速度，而不是它在某個當下的絕對的大小。