第一篇：(1)嘆咖啡
第二篇：(2)第一杯咖啡
第三篇：(3)Eclipse
第四篇：(4)品味第一杯咖啡
第五篇：(5)Java語言基礎
第六篇：(6)編寫猜數字遊戲
歸根結底，計算機的發展史可以歸納為「抽象」兩個字。應用存儲程序的理論，人們從最早的現代計算機抽象出軟體(Software)和硬體(Hardware)兩個獨立部分。為了讓軟體各司其職，軟體又被抽象成專門與硬體打交道的作業系統(Operating System)和建築在作業系統之上的應用軟體(Application)。數據處理又是許多應用軟體必須的前提，從而抽象出資料庫系統(Database System)。到了網絡時代，為了更好地適應網絡軟體的開發，應用軟體中又抽象出應用伺服器(Application Server)提供各種服務。
程式語言的發展亦復如是。讓我們在這回的咖啡館中看看程式語言的發展簡史，從頭認識Java中的面向對象編程技術。
1946年2月15日，隨著第一臺現代電子計算機ENIAC轟鳴著來到這個世界，編寫程序也成為三百六十行之外的一個嶄新職業。我們稱編寫程序的工程師為程式設計師或者開發者。
ENIAC是一臺重達30噸的龐然大物，由19000多個電晶體、1500多個繼電器組成。為了給它下達指令，程式設計師必須通過不同的連接線組合進行編程。要編制運行新的程序，還必須拔掉連線重新來過。整天面對二進位編程的工作相當枯燥乏味，而且是直接對程序地址讀寫，自然出錯頻繁。閱讀由連線表達的程序更不亞於揣摩天書，維護和改造程序的價格成本居高不下。更要命的是，早期的計算機製造價格相當昂貴，而在程序編制調試完成之前，計算機不得不一直空轉，導致軟體開發的費用竟然遠遠超過硬體的投入。
為了解決軟體開發的難題，計算機科學家發明了彙編語言，通過一些助記符來減輕二進位編碼的開發壓力。這的確是行之有效的方法，直到現在，程式設計師在開發中還常常使用嵌入式彙編來提高軟體運行速度，遊戲引擎更是如此。然而，彙編語言太依賴程式設計師的素質，而且無法適應大規模的開發。
黃糖故事 Grace Murray Hopper、Bug和Debug
由於一次傳奇般的投資，Mark I計算機把IBM從生產制表機、肉鋪磅秤、咖啡碾磨機等亂七八糟玩意的行業，領入了計算機製造業的領地，最終成為如今的藍色巨人。本系列文章中曾介紹過Mark I三個程式設計師之一的數學家Grace Hopper是如何創造了「BUG」和「DEBUG」這兩個計算機史上著名的兩個名詞的。而這位Hopper女士，實在是一個不得了的人物。1952年，Hopper覺得用機器碼編程是不是比較原始，為什麼不能用類自然語言編寫程序，然後再用一個工具把它轉換成機器碼呢？不久，她就開發出世界上第一套編譯器A-0，是現代編譯技術的原型。1956年她在第一臺儲存程序的商業電子計算機UNIVAC I、II上開發出B-0，之後叫做FLOW-MATIC，它導致了計算機商用語言COBOL(COmmon Business Oriented Language)的誕生。雖然Hopper有著「電腦之母」的美譽，但是傳說她辦公室有一個倒著走的鐘，以及一面秀著骷髏頭的海盜旗。
到了六十年代，FORTRAN (FORmula TRANslating)、COBOL、LISP、ALGOL 60等現代高級語言的出現了。程式設計師可以用接近自然語言的程序語言編制軟體，然後通過編譯器轉換成機器可執行的代碼。由於使用精確的形式語言來定義程序語言本身，並且通過對硬體的抽象使得程序與計算機平臺無關，導致高級語言生產效率大大提高，維護費用自然降低不少，計算機軟體業終於得以蓬勃發展。
好景不長。隨著軟體大規模的應用，程序的開發方法和管理手段逐漸無法跟上軟體規模的膨脹，從而導致了軟體危機的出現。就拿1963～1966年間的IBM 360系統來說，該系統有100萬行的代碼量，IBM每年動用5000人來維護該系統，但是，每個版本都是從上一個版本找出1000以上個錯誤而修訂的結果，好像越改錯誤越多，根本沒有改善的跡象。有人把IBM 360系統形容為一隻逃亡的野獸落到泥潭中做垂死的掙扎，越是掙扎，陷的越深，最後仍然無法逃脫滅頂的災難。
人們不得不停下腳步思考，到底哪裡出了問題。回想自己，每個人做事情，都是列舉重點，然後細化並逐個完成。比如製造自行車，肯定是先把自行車按照功能分塊，先造車架，然後是兩個車輪，接著是踏板等傳動裝置，最後才是坐墊、車鈴等零件。而製造車輪，肯定是要分別製造鋼圈、鋼絲、輪胎，而輪胎有分內外胎。如果軟體開發能夠遵循這種從大到小、逐步精確的思想，是不是能夠解決這個軟體危機呢？
沒錯，這種結構化的抽象分析方法，導致了結構化程序設計方法的誕生。
黃糖故事 Niklaus Wirth和PASCAL
凡是學過一點計算機知識的人大概都知道「數據結構＋算法二程序」這一著名公式。提出這一公式的瑞士計算機科學家Niklaus Wirth由於發明了多種影響深遠的程序設計語言，並提出結構化程序設計這一革命性概念而獲得了1984年的圖靈獎。
Wirth開發的PASCAL在數據結構和過程控制結構方面都有很多創造，比如Java中字符型、引用型，以及if-then-else、while、for等多種控制結構，都是從PASCAL裡面借鑑發展而來的。可以說，現代程序設計語言中常用的數據結構和控制結構絕大多數都是由PASCAL語言奠定基礎的，因此PASCAL在程序設計語言的發展史上具有承上啟下的重要裡程碑意義。現在你知道為什麼很多計算機專業的學生都要學PASCAL語言了吧。
1971年，Wirth基於其開發程序設計語言和編程的實踐經驗，首次提出了「結構化程序設計」(structured programming)的概念。這個概念的要點是:不要求一步就編製成可執行的程序，而是分若干步進行，逐步求精。第一步編出的程序抽象度最高，第二步編出的程序抽象度有所降低……最後一步編出的程序即為可執行的程序。用這種方法編程，似乎複雜，實際上優點很多，可使程序易讀、易寫、易調試、易維護、易保證其正確性及驗證其正確性。結構化程序設計方法又稱為「自頂向下」或「逐步求精」法，在程序設計領域引發了一場革命，成為程序開發的一個標準方法，尤其是在後來發展起來的軟體工程中獲得廣泛應用。有人評價說沃思的結構化程序設計概念「完全改變了人們對程序設計的思維方式」，這是一點也不誇張的。
黃糖故事 Philippe Kahn的Borland傳奇
Wirth開發PASCAL的初衷是為了有一個適合於教學的語言。但一經推出，由於它的簡潔明了、提供豐富的數據結構和控制結構，使得程序開發大為簡便，竟然大受歡迎。在C語言問世以前，PASCAL是風靡全球、最受歡迎的語言之一，不但創下了發行拷貝數最多的世界記錄，而且成為大學數據結構教學的「惟一官方指定」語言。
Phillipe Kahn是Niklaus Wirth的學生，畢業後到美國加利福尼亞州創立了Borland公司，憑藉拳頭產品Turbo PASCAL，當時就賣出了100多萬個拷貝，成為百萬富翁。而Borland公司是程式設計師津津樂道到程序開發工具供應商，他們從最早的Turbo PASCAL、Turbo C、Turbo PROLOG等Turbo系列，到如今的Delphi、C++ Builder、JBuilder、C# Builder系列，無一不是舉足輕重的開發工具，從而在開發者心目中有著崇高的地位。
雖然結構化程序設計使得程式設計師世界觀經歷了巨大變革，行之有效地解決了軟體開發中的許多問題，然而，結構化程序設計並不能完全解決軟體危機，人們仍然渴望生產效率更高、更可靠、易維護、易管理的開發思想和開發方法。
實際上，人們認識世界，是有一些基本的法則的:
?區分事物及其屬性，如自行車和車子的顏色。
?區分整體對象及其組成部分，如區分自行車和車輪。
?不同對象類的形成及其區分，如山地自行車和兩人休閒車雖然有相當的區別，但都屬於自行車這個類型。
心理學研究表明，把客觀世界由許多對象組成，對象具有其屬性和行為，之間存在著各種聯繫，這樣能夠更好的刻畫問題域，也更接近人類的自然思維方式。這就是面向對象程序開發思想的由來。
對象的概念最早出現於五十年代人工智慧的早期著作中，而OO(面向對象)的實際發展始於1966年的Kisten Nygaard和Ole-Johan Dahl開發的Simula語言。正如名字昭示的，Simula可以模擬客觀世界。比如在著名的銀行出納問題中，你可以創建若干個出納員對象，若干個客戶對象，還有若干錢對象以及交易對象(即把存款、提款等交易動作看成一個對象)?? 這個世界是由對象組成的。所有出納員對象，除了各自的狀態不同，都是屬於的出納員這個抽象類別。出納員對象和客戶對象之間通過消息傳遞進行交互，並且最終生成若干個交易對象，而交易對象可以操縱錢對象，完成存款或者提款的動作。
你看，這個銀行櫃檯世界，是不是完全可以由對象模擬呢？從而，面向對象設計程序，主要就是設計抽象的類。
面向對象程序設計思想是一個裡程碑。Alan Kay設計了世界上第一個完全面向對象的語言Smalltalk並成為圖靈獎得主，Bjarne Stroustrup明智地把面向對象和最流行的C語言結合而開發了有史以來取得最大成功的C++語言，Anders Hejlsberg把PASCAL的面向對象版本Object PASCAL結合構件的思想開發出Windows平臺上最優秀的快速程序開發(RAD)工具之一Delphi，James Gosling結合Internet背景開發了本咖啡館賴以謀生計的Java語言，Bill Gates把.Net體系結構完全構築在面向對象之上……
黃糖故事 「面向對象」與「物件導向」
閱讀臺灣技術作家的文章時經常會遇到「物件導向」一詞。實際上，這是港澳臺地區的計算機科學家對「Object Oriented」的翻譯，與我們所說的「面向對象」是一回事情。不過，如果仔細從OO的理念品評一下兩者的味道，似乎「物件導向」這個翻譯更雅，更原汁原味。
雖然面向對象只是從語法上引入為面向對象服務的封裝、繼承、多態等概念，但是必須看到，OO並非一種特殊的規定或者行業規範，而是一個優秀的理念，學習Java，應該把OO當作指導思想。