245
連載：麵向對象葵花寶典：思想、技巧與實踐（1） - 程序設計思想的發展
史前時代：麵向機器
最早的程序設計都是采用機器語言來編寫的，直接使用二進製碼來表示機器能夠識別和執行的指令和數據。簡單來說，就是直接編寫0和1的序列來代表程序語言。例如：使用0000 代表 加載（LOAD），0001 代表 存儲（STORE）等。
機器語言由機器直接執行，速度快，但一個很明顯的缺點就是：寫起來實在是太困難了，一旦你發現自己寫錯了，改起來更蛋疼！這樣直接導致程序編寫效率十分低下，編寫程序花費的時間往往是實際運行時間的幾十倍或幾百倍。
有一個關於機器語言和比爾蓋茨的笑話，是說比爾蓋茨拿著繡花針在一張光盤上戳，把Windows給戳出來了！但如果真的讓你去戳，不要說Windows，連一個簡單的“Hello world”都要讓人戳到眼睛冒煙！
由於機器語言實在是太難編寫了，於是就發展出了匯編語言。匯編語言亦稱符號語言，用助記符代替機器指令的操作碼，用地址符號（Symbol）或標號（Label）代替指令或操作數的地址，。匯編語言由於是采用了助記符號來編寫程序，比用機器語言的二進製代碼編程要方便些，在一定程度上簡化了編程過程。例如使用LOAD 來代替 0000，使用STORE來代替0001。
即使匯編語言相比機器語言提升了可讀性，但其本質上還是一種麵向機器的語言，編寫同樣困難，也很容易出錯。相信很多計算機畢業的學生至今都對學校的匯編課程中的練習程序心有餘悸。
脫離機器第一步：麵向過程
麵向機器的語言通常情況下被認為是一種“低級語言”，為了解決麵向機器的語言存在的問題，計算機科學的前輩們又創建了麵向過程的語言。麵向過程的語言被認為是一種“高級語言”，相比麵向機器的語言來說，麵向過程的語言已經不再關注機器本身的操作指令、存儲等方麵，而是關注如何一步一步的解決具體的問題，即：解決問題的過程，這應該也是麵向過程說法的來由。
相比麵向機器的思想來說，麵向過程是一次思想上的飛躍，將程序員從複雜的機器操作和運行的細節中解放出來，轉而關注具體需要解決的問題；麵向過程的語言也不再需要和具體的機器綁定，從而具備了移植性和通用性；麵向過程的語言本身也更加容易編寫和維護。這些因素疊加起來，大大減輕了程序員的負擔，提升了程序員的工作效率，從而促進了軟件行業的快速發展。
典型的麵向過程的語言有：COBOL、FORTRAN、BASIC、C語言等。
第一次軟件危機：結構化程序設計
隨著計算機硬件的飛速發展，以及應用複雜度越來越高，軟件規模越來越大，原有的程序開發方式已經越來越不能滿足需求了。1960年代中期開始爆發了第一次軟件危機，典型表現有軟件質量低下、項目無法如期完成、項目嚴重超支等，因為軟件而導致的重大事故時有發生。例如1963年美國（https://en.wikipedia.org/wiki/Mariner_1） 的水手一號火箭發射失敗事故，就是因為一行FORTRAN代碼錯誤導致的。
軟件危機最典型的例子莫過於IBM的System/360的操作係統開發。佛瑞德·布魯克斯（Frederick P. Brooks, Jr.）作為項目主管，率領2000多個程序員夜以繼日的工作，共計花費了5000人一年的工作量，寫出將近100萬行的源碼，總共投入5億美元，是美國的“曼哈頓”原子彈計劃投入的1/4。盡管投入如此巨大，但項目進度卻一再延遲，軟件質量也得不到保障。布魯克斯後來基於這個項目經驗而總結的《人月神話》一書，成了史上最暢銷的軟件工程書籍。
為了解決問題，在1968、1969年連續召開兩次著名的NATO會議，會議正式創造了“軟件危機”一詞，並提出了針對性的解決方法“軟件工程”。雖然“軟件工程”提出之後也曾被視為軟件領域的銀彈，但後來事實證明，軟件工程同樣無法解決軟件危機。
差不多同一時間，“結構化程序設計”作為另外一種解決軟件危機的方案被提出來了。 Edsger Dijkstra 於1968發表了著名的《GOTO有害論》的論文，引起了長達數年的論戰，並由此產生了結構化程序設計方法。同時，第一個結構化的程序語言Pascal也在此時誕生，並迅速流行起來。
結構化程序設計的主要特點是拋棄goto語句，采取“自頂向下、逐步細化、模塊化”的指導思想。結構化程序設計本質上還是一種麵向過程的設計思想，但通過“自頂向下、逐步細化、模塊化”的方法，將軟件的複雜度控製在一定範圍內，從而從整體上降低了軟件開發的複雜度。結構化程序方法成為了1970年代軟件開發的潮流。
科學研究證明，人腦存在人類短期記憶一般一次隻能記住5-9個事物，這就是著名的 7+- 2原理。結構化程序設計是麵向過程設計思想的一個改進，使得軟件開發更加符合人類思維的7+-2特點。
第二次軟件危機：麵向對象程序設計
結構化編程的風靡在一定程度上緩解了軟件危機，然而好景不長，隨著硬件的快速發展，業務需求越來越複雜，以及編程應用領域越來越廣泛，第二次軟件危機很快就到來了。
第二次軟件危機的根本原因還是在於軟件生產力遠遠跟不上硬件和業務的發展，相比第一次軟件危機主要體現在“複雜性”，第二次軟件危機主要體現在“可擴展性”、“可維護性”上麵。傳統的麵向過程（包括結構化程序設計）方法已經越來越不能適應快速多變的業務需求了，軟件領域迫切希望找到新的銀彈來解決軟件危機，在這種背景下，麵向對象的思想開始流行起來。
麵向對象的思想並不是在第二次軟件危機後才出現的，早在1967年的Simula語言中就開始提出來了，但第二次軟件危機促進了麵向對象的發展。 麵向對象真正開始流行是在1980s年代，主要得益於C++的功勞，後來的Java、C#把麵向對象推向了新的高峰。到現在為止，麵向對象已經成為了主流的開發思想。
雖然麵向對象開始也被當做解決軟件危機的銀彈，但事實證明，和軟件工程一樣，麵向對象也不是銀彈，而隻是一種新的軟件方法而已。
雖然麵向對象並不是解決軟件危機的銀彈，但和麵向過程相比，麵向對象的思想更加貼近人類思維的特點，更加脫離機器思維，是一次軟件設計思想上的飛躍。
========================================================================
轉載請注明出處：https://blog.csdn.net/yunhua_lee/article/details/17249863
========================================================================
最後更新：2017-04-03 12:53:42