對象導論之抽象過程

抽象過程
　　所有編程語言都提供抽象機制。可以認爲，人們所能夠解決的問題的複雜性直接取決於抽象的類型和質量。所謂的“類型”是指“所抽象的是什麼？”彙編語言是對底層機器的輕微抽象。接着出現的許多所謂“命令式”語言（如FORTRAN,BASIC,C等）都是對彙編語言的抽象。這些語言在彙編語言的基礎上有了大幅的改進，但是它們所做的主要抽象仍要求在解決問題時要基於計算機的結構，而不是基於所要解決的問題的結構來考慮。程序員必須建立起在機器模型（位於“解空間”內，這是你對問題建模的地方，例如計算機）和實際待解問題的模型（位於“問題空間”內，這是問題存在的地方，例如一項業務）之間的關聯。建立這種映射是費力的，而且這不屬於編程語言所固有的功能，這使得程序難以編寫，並且維護代價高昂，同時也產生了作爲副產物的整個“編程方法”行業。
　　另一種對機器建模的方式就是隻針對待解決問題建模。早期的編程語言，如LISP和APL，都選擇考慮世界的某些特定視圖（分別對應“所有問題最終都是列表”或者“所有問題都是算法形式的”）。PROLOG則將所有問題都轉換成決策鏈。此外還產生了基於約束條件編程的語言和專門通過對圖形符號操作來實現編程的語言（後者被證明限制性過強）。這些方式對於它們所要解決的特定類型的問題都是不錯的解決方案，但是一旦超出其特定領域，它們就力不從心了。
　　面向對象方式通過向程序員提供表示問題空間中的元素工具而更進一步了。這種表示方式非常通用，使得程序員不會受限於任何特定類型的問題。我們將問題空間中的元素及其在解空間中的表示稱爲“對象”。（你還需要一些無法類比爲問題空間元素的對象。）這種思想的實質是：程序可以通過添加新類型的對象使自身適用於某個特定問題。因此，當你在閱讀描述解決方案的代碼的同時，也是在閱讀問題的表述。相比以前我們所使用的語言，這是一種更靈活和更強有力的語言抽象。所以，OOP允許根據問題來描述問題，而不是根據運行解決方案的計算機來描述問題。但是它仍然與計算機有聯繫：每個對象看起來都有點像一臺微型計算機——它具有狀態，還具有操作，用戶可以要求對象執行這些操作。如果要對現實世界中的對象做類比，那麼說它們都具有特徵和行爲似乎不錯。
　　Alan Kay曾經總結了第一個成功的面嚮對象語言、同時也是Java所基於