1.從機器碼到面向?qū)ο?/h1>

本章節(jié)主要探討是什么驅(qū)動著編程從機器碼發(fā)展到了匯編語言，又從匯編語言發(fā)展到了面向過程編程，最后從面向過程編程發(fā)展到面向?qū)ο缶幊獭Ｍㄟ^這些探討最終明確多年來的軟件工程發(fā)展我們都解決了哪些棘手的問題。

1.1機器碼

在真正的電子計算機誕生初期，沒有有效的編程語言。在這個時期的計算機提供了最基礎的由0和1組成的機器指令來供初代的程序員進行編碼。
用機器碼寫的程序如示例-1-1所示。

101100000000000000000011 000001010000000000110000 001011010000000000000101

示例-1-1 8086機器上完成“s=768+12288-1280”的數(shù)字運算，對應的機器碼

有了示例-1-1所示的機器碼指令后，會將指令編排到打孔紙帶上，輸入到計算機中。如示例-1-2所示。計算機持續(xù)讀取指點上的指令來完成任務。

示例1-2 打孔紙帶示意圖（可以假設有孔為1，無孔為0）

可以想象在通過這種方式進行編程場景大致會是這樣——手里拿著指令手冊來查詢指令所對應的機器碼，然后對紙帶按照指定進行打孔。在計算機應用的早期，計算機所處理的任務多為簡單的數(shù)學問題，也就是說當時的程序員所面臨的問題復雜度在當時看來并不復雜。所以程序員可以快樂地遇到一個問題就打孔一個紙帶然后輸入到計算機進行求解。
但是好景不長，隨著計算機的發(fā)展，計算機所能處理能力越來越復雜，指令集也成百上千地增加，同時程序也越來越長。這時程序員第一次感覺到這些又臭又長，一眼看不到頭的機器碼維護起來是那么令人抓狂。這時的程序員所渴望的就是一種有自然語義的助記符來幫助自己進行編程，匯編語言應運而生。

1.2匯編語言

匯編語言被稱為第二代計算機語言，用一些容易理解和記憶的縮寫單詞來代替一些特定的指令。通過這種方法，人們很容易去閱讀已經(jīng)完成的程序或者理解程序正在執(zhí)行的功能，對現(xiàn)有程序的bug修復以及運營維護都變得更加簡單方便。但計算機的硬件不認識字母符號，這時候就需要一個專門的程序把這些字符變成計算機能夠識別的二進制數(shù)或機器語言（匯編編譯器）。

用匯編語言編寫代碼如示例-1-3所示。

mov ax, 300h add ax, 3000h sub ax, 500h

示例-1-3 8086機器上完成“s=768+12288-1280”的數(shù)字運算，對應的匯編指令
可以看到示例-1-3所示的程序比起示例-1-1來簡單了很多，并且每條指令都是一個人能讀懂的指令。這樣編寫和維護起來就輕松了很多。但是匯編語言還是存在一定的缺陷——程序員依然在面向硬件編程。也就是說我們在編寫程序的時候不是在編寫我們要解決的問題，而是要將問題翻譯成一堆硬件相關的操作。這就要求程序員非常了解底層的硬件結(jié)構。為了屏蔽底層的硬件復雜性，前輩們提出了高級語言。

1.3高級語言

最初的高級語言代表有Fortran、LISP、Cobol等，不過影響最深刻的應該是C語言。有了這些高級語言后程序員不需要關注機器底層的低級結(jié)構和邏輯，而只要關注具體的問題和業(yè)務即可。
用C語言編寫代碼如示例-1-4所示。

int s=768+12288-1280;

示例-1-4 使用C語言完成“s=768+12288-1280”的數(shù)字運算
在擁有了高級編程語言后，程序員的第一個春天到來了。由于高級語言對底層硬件的屏蔽，讓編程的門檻大幅降低。越來越多的人參與到程序編寫，越來越多的業(yè)務也通過編程軟件來進行實現(xiàn)。但好景不長，隨著軟件的規(guī)模和復雜度的大大增加，20世紀60年代中期開始爆發(fā)了第一次軟件危機，典型表現(xiàn)有軟件質(zhì)量低下、項目無法如期完成、項目嚴重超支等，因為軟件而導致的重大事故時有發(fā)生。
之所以發(fā)生這樣的危機，究其根源便是軟件編碼過于隨意，缺乏有效的代碼組織和模塊劃分。為了解決這次危機面向過程（結(jié)構化程序設計）的編程思想被正式提出。

1.4面向過程編程

面向過程編程的核心思想是“自頂向下、逐步細化、模塊化”。在這種思想的指導下，面向過程編程以過程（可以理解為方法、函數(shù)、操作）作為組織代碼的基本單元。面向過程風格是一種流程化的編程風格，通過拼接一組順序執(zhí)行的方法來操作數(shù)據(jù)完成一項功能。
在這種指導思想的基礎上，程序員首先會用流程圖分析出解決問題的每一個步驟，然后使用函數(shù)將每一個步驟進行實現(xiàn)，最后使用條件判斷和循環(huán)將這些函數(shù)組織在一起來實現(xiàn)業(yè)務邏輯。在這個過程中程序員將大段代碼拆分成了一個個獨立的函數(shù)，最終得到的就是層層調(diào)用的函數(shù)，就可以將復雜的業(yè)務分解成簡單的任務。這種方式以函數(shù)為單元，將相關業(yè)務緊密內(nèi)聚在函數(shù)內(nèi)部，最終達到高內(nèi)聚低耦合的目標。
有了一個又一個的函數(shù)來封裝重復的功能，代碼的可維護性和重用能力都大大提高了。
這時程序員在面對復雜的業(yè)務邏輯時已經(jīng)可以進行很好的應對了。但是隨著軟件行業(yè)的發(fā)展越來越迅速，需求變化也就越來越頻繁。為了適應各種場景，面向過程的編碼往往會存在著大量的條件判斷語句——大體就是條件1該走設么邏輯，條件2該走什么邏輯，條件3等等。隨著這些特殊邏輯的增加，本身清晰的代碼邏輯不再清晰，新增一個條件判斷是要在很多地方進行修改等等讓軟件變得越來越難維護的噩夢開始出現(xiàn)。最終導致軟件的聲明周期變短——重新開發(fā)。
其根本原因來自于面向過程編程在應對軟件擴展時缺乏有效的手段。所以面向?qū)ο缶幊瘫愫糁隽恕?/p>

1.5面向?qū)ο缶幊?/h2>

為了能夠更好地應對需求變化所帶來的軟件開發(fā)復雜性，構建具有擴展性的代碼的需求越來越迫切。而面向?qū)ο缶幊趟坪蹙统闪讼傻っ钏帯Ｍㄟ^以“封裝”、“繼承”和“多態(tài)”三大基礎特性為基礎，以“單一原則”、“開閉原則”和“里氏替換"等原則性的定理為發(fā)展，最后誕生了設計模式以及完整的代碼重構理論這些過程的不斷完善，程序員可以基于面向?qū)ο蟮木幊虂硗瓿涩F(xiàn)代軟件開發(fā)中的各種復雜問題。
基于面向?qū)ο蟮木幊趟枷雭磉M行軟件設計產(chǎn)出的結(jié)果就是一個一個的擁有屬性和行為的對象之間的相互調(diào)用。并且這些對象都是所謂的“充血模型”。

1.6總結(jié)

從機器碼到面向?qū)ο缶幊痰倪^程中，以引入了一層一層的中間層作為代價，最終得到了一種以“對象”為核心的抽象編程模式。這種抽象編程模式符合人類對自然的抽象——我們會描述一個人有眼睛、鼻子等，這些都是人的屬性；描述這個人可以走路、說話這些都是人的行為。在面向?qū)ο螽a(chǎn)生的運行代碼中，就仿佛有這么一群擁有自己特有屬性和行為的“人”在相互協(xié)作來對外提供一個完整的系統(tǒng)功能。

總結(jié)

以上是生活随笔為你收集整理的从机器码到面向对象的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。