Day06 抽象層 (abstraction)


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

什麼是抽象層?

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

模組

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

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

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

介面 (interface) model (模型/模組的內部) 守恆性 (invariants) 假設 (assumptions)
機械時鐘 時針/分針/發條 內部的齒輪構造 內部齒輪轉動的角度與時間之流逝的關系 重力不變、溫度不變、沒有外力去干擾時針分針、放置於平面
Authn/z 模組 login/register/change password API funtions/password hash 每一個「使用者名稱」都不重複 當兩個人知道相同的使用者名稱與密碼時,這兩個人會被此一模組視為是同一個人。

幾種不同的抽象層

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

mathematical deductive inductive
arch model/interface model/interface/env model/interface/env
purpose reasoning tool perfectly predict satisifice/ work well in practical
example complexity analysis/algorithms physics/Prolog/rules engine ordinary software module/biology

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

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

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

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

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

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

bridge of assumption

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

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

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

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

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

#abstraction





Elements of Clojure 一書,談的不只是 Clojure ,而是 senior programmer 了解、卻不易對他人明說的隱性知識 (tacit knowledge)。

留言討論