沒有思想的裸程序就如一副人體骨架，有個(gè)人形，但沒有人樣，骨骼之間的關(guān)節(jié)都是靠膠水或拉線連接起來的，生硬而呆板。如果給骨架包上皮肉，加上靈魂，我們就會(huì)驚嘆：啊！這是帥哥，這是美女！因?yàn)楣羌芑盍恕?/p>

一、裸編程是什么？

先聲明一個(gè)概念，裸編程，指的是在裸機(jī)上編寫程序，裸機(jī)，在單片機(jī)領(lǐng)域就是指帶著硬件的單片機(jī)控制系統(tǒng)，不要想歪咯。

在裸機(jī)上編程，就猶如在一片荒地上開墾，任何一鋤頭下去，都會(huì)碰到硬生生的石頭，要說做這有什么味？拓荒者追求的是來年的綠洲。而我們這些開墾裸機(jī)的所謂的工程師們追求的是什么？我們當(dāng)然追求的是完成一個(gè)任務(wù)。

我們一般都自稱是高級(jí)知識(shí)分子，那么我們?cè)谕鼗牡倪^程中應(yīng)該想些什么？當(dāng)然不是想著如何把任務(wù)完成，而應(yīng)該首先想著我們?cè)谙胄┦裁础＠@了是不？繞了就對(duì)了，這一繞就繞出了思想。思想是一個(gè)簡(jiǎn)單的人在一個(gè)復(fù)雜的環(huán)境里做任何事情的統(tǒng)帥，它影響著一個(gè)拓荒者人生的每一個(gè)細(xì)節(jié)，當(dāng)然也包括裸編程本身。

當(dāng)一個(gè)人拿著鋤頭，一鋤又一鋤，汗滴腳下土的時(shí)候，我們能知道他們?cè)谙胧裁磫幔慨?dāng)然這不好說，如果自己去鋤就知道了。但是大抵也差不多，隨便舉幾個(gè)吧：這太陽他娘的怎么這么毒？這石頭他娘的咋這么多？這地種什么最好？這還有多少天能搞完？這樣干太慢了，要是有臺(tái)機(jī)械搞多好。當(dāng)然這只是一部分，任何人可以想出很多想法來。

那么當(dāng)我們?cè)诼銠C(jī)上拓荒的時(shí)候，我們?cè)撓胄┦裁矗?strong style="color:rgb(68,17,12);">也許我們一般的想法是：先把一個(gè)簡(jiǎn)單的功能做了，先把一個(gè)重要的功能做了，今天終于把這個(gè)功能調(diào)試好了明天可以做下一個(gè)功能了，這個(gè)為什么不是我想象的那樣的結(jié)果？真是莫名其妙！也等等一下吧。

如果拿來一個(gè)任務(wù)，搭好測(cè)試平臺(tái)就開始做程序，想著一個(gè)功能一個(gè)功能的湊完，然后就自我陶醉著成功的喜悅，那這樣做程序，基本就叫做沒思想。有思想的做程序，是不能一下去就堆積源碼的，因?yàn)槟菢又粫?huì)讓一堆生硬的數(shù)字怯生生的擠在一起，不管他們有沒有多余，有沒有矛盾。所以寫源碼之前，是要想想如何寫的。也許很多人在寫之前都想過類似的問題，比如把任務(wù)模塊化后再組織程序。但是這樣的想法只是任務(wù)上的事情，而并不是裸編程時(shí)的思想，裸編程的思想，應(yīng)該是在組織任務(wù)模塊過程中及編寫裸程序時(shí)影響源碼組織的指導(dǎo)思想，它直接決定著源碼的質(zhì)量。

一個(gè)數(shù)據(jù)結(jié)構(gòu)，一個(gè)模塊形成，一個(gè)單片機(jī)的指令，一個(gè)硬指令的運(yùn)行機(jī)制，一個(gè)口線的驅(qū)動(dòng)方式，一個(gè)中斷的順序，一個(gè)跳變的延遲，一個(gè)代碼的位置，一個(gè)邏輯的組織，一個(gè)模塊與模塊之間的生(運(yùn)行時(shí)的狀態(tài))死(不運(yùn)行時(shí)的狀態(tài))關(guān)系等等，都是裸程序思想的組成部分。

這似乎很瑣碎，但是裸程序原本就如此，它不同于上位機(jī)程序，有一個(gè)強(qiáng)大完善的操作系統(tǒng)支持。單片機(jī)里不可能植入操作系統(tǒng)，那樣做就變味了，可不要有人跳出來說，某某某單片機(jī)就有操作系統(tǒng)了。裸程序就應(yīng)該是建立在赤裸裸的硬件基礎(chǔ)上的程序，只有有用的功能才有代碼，裸程序的質(zhì)量也許經(jīng)常在應(yīng)用中感覺不出來，也許你做和他做都能實(shí)現(xiàn)功能，但是好的裸程序有良好的可擴(kuò)充性、可維護(hù)性，系統(tǒng)具有高穩(wěn)定性和高性能。

而追求這種高品位的技術(shù)境界，就必須要有好的思想來指導(dǎo)。是不是看著有些迷糊？別說看得迷糊，我說都說迷糊了，總的來說，就是把一個(gè)優(yōu)秀的靈魂，植入你的源碼中，讓你的源碼具有一個(gè)優(yōu)良的思想。

二、裸編程具體做法

前文說到裸編程要有思想，也許還不夠具體，接下來就是要具體說裸編程的思想的具體做法。

沒有思想的裸程序就如一副人體骨架，有個(gè)人形，但沒有人樣，骨骼之間的關(guān)節(jié)都是靠膠水或拉線連接起來的，生硬而呆板。如果給骨架包上皮肉，加上靈魂，我們就會(huì)驚嘆：啊！這是帥哥，這是美女！因?yàn)楣羌芑盍恕?/p>

裸程序也一樣，如果按傳統(tǒng)的思維方式說這樣就足夠了，那么裸程序就形如骨架，通常只是一些功能的粗糙堆砌，也只會(huì)叫后人看了說這程序垃圾，而后人再做也未必能跳出這個(gè)圈子，那么后后人看了又叫這程序垃圾，如此下去，代代相傳，傳了什么？傳了一個(gè)總被叫垃圾的東西：無思想的裸程序。

我做了程序好多年，也思考了編程好多年，不斷的經(jīng)驗(yàn)積累告訴我：寫好的程序不是如何去完成代碼，而是如何去組織代碼。上位機(jī)中面向?qū)ο蟮木幊趟枷耄褪且粋€(gè)非常可取的思想。

面向?qū)ο蟮木幊趟枷朐谏衔粰C(jī)中是有一個(gè)非常豐富的開發(fā)包和功能強(qiáng)大的操作系統(tǒng)支持的，裸編程如何引入這樣的思想呢？也許很多人會(huì)覺得不可能。

其實(shí)，沒有什么是不可能的。再復(fù)雜的思想，最終都會(huì)歸結(jié)到匯編，歸結(jié)到裸程序，我們的單片機(jī)程序，正是一種裸程序。只是在單片機(jī)編程時(shí)和微機(jī)編程時(shí)我們站在開發(fā)平臺(tái)上的高度不一樣，而已！

對(duì)這個(gè)高度的理解，也許很多人很困惑，因?yàn)槲覀兤綍r(shí)很少注意它們，那么這里我就舉個(gè)其他的例子來說明，盡管和裸編程好象不很相關(guān)，但是這個(gè)例子里的高度概念十分清晰。

我們知道網(wǎng)絡(luò)傳輸標(biāo)準(zhǔn)層次有七層：應(yīng)用層、表示層、會(huì)話層、傳輸層、網(wǎng)絡(luò)層、鏈路層、物理層，這么多層做什么用？也許理解這樣分層的概念也十分辛苦，但是理解這樣分層的思想，就容易多了，而且這也是我們硬件工程師們最應(yīng)該借鑒的思想，讓我們的硬件設(shè)計(jì)更具有標(biāo)準(zhǔn)性和前瞻性。

這個(gè)七層的思想從根本上講就是將一個(gè)網(wǎng)絡(luò)傳輸產(chǎn)品細(xì)化，讓不同的制造商選擇一個(gè)適合自己的層次開發(fā)自己的產(chǎn)品，層次不一樣，他們所選擇的開發(fā)基礎(chǔ)和開發(fā)內(nèi)容就不一樣，高一層開發(fā)者繼承低層開發(fā)者的成果，從而節(jié)省社會(huì)資源，提高社會(huì)生產(chǎn)力。對(duì)這個(gè)指導(dǎo)思想我就不贅述了，各位自己去理解，這里要說的是，微機(jī)上的面向?qū)ο缶幊趟枷刖褪侨缤趹?yīng)用層上實(shí)現(xiàn)的思想，而裸程序的面向?qū)ο笏枷雱t如同在鏈路層上實(shí)現(xiàn)的思想，他下面沒有軟件開發(fā)包，只有物理構(gòu)架。但是在應(yīng)用層上實(shí)現(xiàn)的思想，最終都要翻譯到物理構(gòu)架上。

看懂了上面的例子，就一定明白，裸程序的面向?qū)ο笏枷耄强梢詫?shí)現(xiàn)的，只是難度要大得多，理解要難得多。但是這不要緊，這正是軟件水平的表現(xiàn)，你喜歡技術(shù)，又何懼之？其實(shí)也不會(huì)難到哪里去，只是把做事情的方式稍微改變一下而已。

傳統(tǒng)上我們都喜歡用功能來劃分模塊，細(xì)分任務(wù)，面向?qū)ο笏枷氩贿@樣。面向?qū)ο笏枷雱t是先從一個(gè)任務(wù)中找出對(duì)象，在對(duì)象中攙雜些模塊等來實(shí)現(xiàn)功能的。這就是兩種風(fēng)格截然不同的地方。比如我們要讓我們的單片機(jī)把顯示信息輸出到顯示器，那么傳統(tǒng)的分析方法是信息格式化、格式化數(shù)據(jù)送顯示器顯示，似乎這樣也就足夠了，不同的顯示器用不同的送顯示程序或者程序段，配置不同的變量，能共的共起來，不能共的分開。

但是面向?qū)ο蟮乃枷氩皇沁@樣做的，而是首先把顯示器當(dāng)作一個(gè)對(duì)象，該對(duì)象具有一些功能和一些變量屬性，不同的顯示器在對(duì)象中使用相同的代碼標(biāo)識(shí)，如函數(shù)指針（C語言中），這樣對(duì)于任何一個(gè)不同的顯示器，在調(diào)用時(shí)都使用同樣的代碼。也許有人說，傳統(tǒng)的做法這樣也可以做呀，為什么要弄得羅里吧唆的呢？其實(shí)不然，使用了正確的思想的好處在前頭已經(jīng)說了好多了，如果還模糊就上去再看一次。

說了那么多理論，現(xiàn)在就說些具體的做法吧。以KeilC為編譯環(huán)境來說說一個(gè)對(duì)象具體組織的一些做法。首先是找出對(duì)象，如顯示器，這就是一個(gè)典型的對(duì)象。其次是分析一個(gè)活對(duì)象所應(yīng)具有的基本特征，即屬性與動(dòng)作。顯示器的屬性如：類型代號(hào)、亮度、對(duì)比度、顯存等，動(dòng)作如：初始化、內(nèi)容刷新和顯示、開啟和關(guān)閉、內(nèi)容閃爍等花樣顯示等。這樣分也比較容易理解，下面是對(duì)于代碼的組織上，要注意對(duì)象的獨(dú)立性與完整性，首先把顯示器對(duì)象單獨(dú)放在一個(gè)文檔上，屬于對(duì)象特有的變量與對(duì)象的定義放在一起，要區(qū)分公有變量與私有變量的定義方式，對(duì)于私有變量要考慮臨時(shí)變量與永久變量的安排，這些安排都是對(duì)變量生命期的嚴(yán)格確定，這樣可以節(jié)省內(nèi)存，避免混亂。如某一個(gè)函數(shù)要使用一個(gè)變量，函數(shù)在調(diào)用完了就退出了，而有一個(gè)變量只有它使用，卻要保存每一次調(diào)用函數(shù)所產(chǎn)生的結(jié)果，這樣的變量怎么定義呢？很多人會(huì)直接定義一個(gè)全局變量，但是一個(gè)好的做法是把這個(gè)變量定義成該函數(shù)的局部變量，但是定義成靜態(tài)的，那么這樣這個(gè)變量對(duì)其他代碼就是透明的，完全不可能會(huì)被誤修改，而且代碼分類性好，便于將來的維護(hù)。用函數(shù)指針來統(tǒng)一不同類型的顯示器不同的處理方式，也是一個(gè)很好的處理辦法，那樣可以讓具體處理方式千差萬別的顯示器都能用一個(gè)統(tǒng)一的對(duì)象，但是函數(shù)指針要慎重使用。

好了，說長(zhǎng)了我就頭暈，不說了，思想的精華，不必有一樣的形態(tài)，不同的人會(huì)有不同的理解，我只希望能給大家的程序生涯拋磚引玉，我就覺得很有成就感了。

三、準(zhǔn)備工作

本文在此引用一個(gè)例子。在引入例子之前，我們要做一些準(zhǔn)備工作，然后一步一步地走向例子里去。就以前面帖子提到過的顯示器控制為例。

顯示器就是一個(gè)對(duì)象。無論它是功能多么復(fù)雜的顯示器，或者功能多么簡(jiǎn)單的顯示器，對(duì)于需要顯示信息的調(diào)用者來說，都并不重要，也就是說對(duì)于需要使用顯示器的主體來講，他只管顯示信息，不管顯示器的千差萬別，只要顯示器提供了某功能，它可以調(diào)用就行，調(diào)用前當(dāng)然要遵守顯示器的數(shù)據(jù)傳遞規(guī)則，但是不必考慮不同的顯示器所產(chǎn)生的傳遞規(guī)則的差異。也就是說，對(duì)于調(diào)用者來說，永遠(yuǎn)不會(huì)希望有多條規(guī)則來讓自己的調(diào)用代碼變復(fù)雜。

因此，我們首先需要構(gòu)造一個(gè)相對(duì)獨(dú)立的代碼段，也就是顯示器對(duì)象，以下都以KeilC作為裸程序的編譯環(huán)境。正如很多人說的，KeilC并不是OOP語言，那怎么做？正是因?yàn)槲覀冋J(rèn)為KeilC不能做，所以我才把這種思想拿出來與大家探討，讓我們的程序變得更精彩，更有技術(shù)含量。

形成一個(gè)獨(dú)立代碼段，最好的辦法就是在主工程目錄下建立一個(gè)子目錄，如DISPLAY，然后再在DISPLAY目錄下建立一個(gè)文檔，如DISPLAY.H，然后把DISPLAYDISPLAY.H文檔#include到一個(gè)恰當(dāng)?shù)奈恢蒙希@樣，一個(gè)獨(dú)立的面向?qū)ο蟮拇a段就初步形成了，以后維護(hù)代碼的時(shí)候，你永遠(yuǎn)不要考慮調(diào)用者是什么感受，只要維護(hù)這個(gè)文檔，就可以保證你對(duì)顯示器的不斷更新了。

很多人也許會(huì)說，這算什么OOP？大家先別著急，這才是個(gè)開始，下面才是組織代碼的具體過程。

對(duì)于一個(gè)顯示器，我們必須要有顯示要求，我們才會(huì)去定制它，如果連使用要求都提不出來，就不要去讓人為你做顯示器。所以我們首先要明確我們要的顯示器必須要做什么。由于是單片機(jī)控制的顯示器，我們不能想象成微機(jī)顯示器那樣，一個(gè)大的顯存，可以顯示多少頁，顯示多少色，滿屏滿屏的傳遞數(shù)據(jù)，如果這樣想了，就是犯了盲目例比的錯(cuò)誤，說明對(duì)問題沒研究透。對(duì)于單片機(jī)控制的顯示器，我們考慮能顯示單個(gè)字符、單行顯示，就基本足夠了。所以我們可以定義下列兩個(gè)對(duì)象功能：

dispShowAChar（）;//顯示一個(gè)字符
dispShowALine（）;//顯示一行字符

由于是單片機(jī)的裸系統(tǒng)，所以我們作為一個(gè)軟件設(shè)計(jì)者，我們一定要清楚，我們所面對(duì)的顯示器，經(jīng)常是沒有CPU的，所以我們一定要明白，我們這兩個(gè)函數(shù)，實(shí)質(zhì)上都做些什么。很顯然，這兩個(gè)函數(shù)是不能長(zhǎng)期占有CPU的，否則我們的程序?qū)⑹裁炊疾荒茏觯瑢Ｈワ@示了，成了顯示器的一個(gè)處理芯片，所以這兩個(gè)函數(shù)運(yùn)行完后是肯定要退出來的，而顯示不能中斷呀，所以必須要有一個(gè)代碼段一直存在于活動(dòng)代碼中而且不能影響其他的功能。做過上位機(jī)程序的人應(yīng)該能看出來，這段代碼就是線程。裸編程中我們也用這個(gè)概念。

我們的顯示器對(duì)象正需要一個(gè)一直活動(dòng)的線程，來完成單片機(jī)系統(tǒng)對(duì)顯示功能的解釋和執(zhí)行，因此dispShowAChar()和dispShowALine()實(shí)質(zhì)上是不能直接去做顯示工作的，它倆最合適的工作，就是去按指定的格式去設(shè)置顯示內(nèi)容，這樣我們?cè)谑褂玫臅r(shí)候就不必在這兩個(gè)函數(shù)里設(shè)置復(fù)雜的代碼和嵌套調(diào)用關(guān)系，因?yàn)槟菢右欢〞?huì)浪費(fèi)很多的代碼，調(diào)用多了也會(huì)讓單片機(jī)運(yùn)行效率降低，硬件資源消耗增加，嚴(yán)重的可能會(huì)造成堆棧溢出最后還不曉得為什么。讓我們也為這個(gè)活動(dòng)線程也先命個(gè)名吧：

dispMainThread（）;//按指定的要求執(zhí)行顯示功能
//指定的要求包括顏色信息、閃爍、游動(dòng)等等

程序分析下去，引出的概念也就會(huì)越來越多，這里所說的多線程概念以后有機(jī)會(huì)再說，單片機(jī)里的多線程也是一個(gè)復(fù)雜羅嗦的處理問題，現(xiàn)在介紹還為時(shí)過早。只是我感覺一不小心又說長(zhǎng)了，具體下文繼續(xù)展開。

四、展開思想

對(duì)于對(duì)象能力的定義，我們一般可以從重要的入手，然后慢慢地展開，把所需要的其他能力逐漸歸納為函數(shù)，從而把面向?qū)ο蟮乃枷氚l(fā)展下去。上文我們提到了三個(gè)函數(shù)是怎么來的，還沒有涉及到函數(shù)的任何實(shí)質(zhì)，那么本帖就探討一下這三個(gè)函數(shù)的實(shí)質(zhì)性規(guī)劃與設(shè)計(jì)。

有了功能要求，我們就要實(shí)現(xiàn)它，在裸程序中，實(shí)現(xiàn)它的一個(gè)首要任務(wù)，就是要進(jìn)行數(shù)據(jù)傳遞方式的設(shè)計(jì)。很顯然我們必須要有一個(gè)顯示區(qū)域，來存放我們所要顯示的內(nèi)容，以及顯示內(nèi)容的顯示屬性，我們還要規(guī)劃這個(gè)顯示區(qū)域到底要顯示多少多少字符或者是點(diǎn)陣。但是由于我們事先并不知道我們的顯示設(shè)備一次會(huì)提供多少顯示量，所以我們可以把顯示區(qū)域的內(nèi)存，也就是顯存，定義得大一點(diǎn)，以至任何一款符合設(shè)計(jì)要求的顯示器都能得到滿足，這樣的做法在裸編程中其實(shí)還是比較實(shí)用的，因?yàn)槁憔幊讨形覀兒苌偃ド暾?qǐng)動(dòng)態(tài)的空間，程序設(shè)計(jì)完，所有的變量位置皆已確定，行就行，不行編譯就過不去，所以我們可以通常選擇一些內(nèi)存資源比較豐富的新款單片機(jī)。

但是這樣的做法也有一個(gè)弊端，比如當(dāng)我們預(yù)先估計(jì)不足而導(dǎo)致數(shù)據(jù)空間不夠的時(shí)候，我們就得從頭來改這個(gè)顯存的大小，從而導(dǎo)致整個(gè)顯示程序都要相應(yīng)的產(chǎn)生一些變動(dòng)，這還不是最糟糕的，最糟糕的是當(dāng)一款新的顯示器因?yàn)樾碌墓δ苄枨蠖鴮?dǎo)致數(shù)據(jù)結(jié)構(gòu)需要發(fā)生變化的時(shí)候，我們就崩潰了，前期的工作可能改動(dòng)就非常大，甚至于都要重新過一遍，也就是重寫重調(diào)，這么痛苦的事情，我是最討厭的了。

所以我們要盡量避免這類事情發(fā)生，這里對(duì)面向?qū)ο蟮乃枷耄皖H為需求了。這個(gè)時(shí)候，我們就要引入一個(gè)新的概念，那就是對(duì)象的兒子，子對(duì)象。前面討論的，其實(shí)都只是一個(gè)抽象的對(duì)象，沒有任何具體的樣子，而只是籠統(tǒng)的規(guī)劃了所有的顯示器必須具有什么能力，而對(duì)于每一個(gè)具體的顯示器來說，還沒有任何具體的設(shè)計(jì)，在這里，每一個(gè)具體的顯示器，就是顯示器對(duì)象的子對(duì)象，他們形態(tài)各異，但是都必須能完成規(guī)定的功能。以傳統(tǒng)的OOP語言理論來說，這里就產(chǎn)生了一個(gè)繼承的關(guān)系，但是在裸程序思想里，我并不贊成引入這個(gè)概念，因?yàn)閭鹘y(tǒng)的OOP語言里的繼承，純粹是一個(gè)語法上的邏輯關(guān)系，繼承關(guān)系明確，而裸程序中的這個(gè)思想，并沒有任何語法支持，繼承關(guān)系就非常微弱了，還不如說是歸類與概括。但無論是什么關(guān)系，我還是不想就這種一目了然的關(guān)系弄個(gè)新名詞來，讓看的人費(fèi)解。

既然引入了子對(duì)象，我們能看出這種做法有什么實(shí)際意義嗎？也許有經(jīng)驗(yàn)的資深程序員能看出來。我們?cè)谧龈笇?duì)象數(shù)據(jù)設(shè)計(jì)的時(shí)候，我們并不規(guī)定具體的數(shù)據(jù)格式和顯存大小，而是一股腦兒地全推給子對(duì)象自己去搞，父對(duì)象什么都不管。哈哈！這樣做事情真是很簡(jiǎn)單吧？不是我的事情我不管，不要說我偷懶，因?yàn)檎驹诟笇?duì)象的角度講，這是最明智的做法，因?yàn)楣懿涣耍圆还堋?/p>

到這里也許就會(huì)產(chǎn)生更多的疑問了，一個(gè)對(duì)象什么都不管，那作為調(diào)用者怎么使用這個(gè)對(duì)象呢？你想用它，它什么都不管，這怎么行呀？別著急，父對(duì)象不管的，是那些具體的事情，抽象的事情，還是管的，要不然它就沒有理由存在了。你抱怨了，說明你在思考，既然思考了，就把思考的問題提出來，提出來的，就是我們?cè)O(shè)計(jì)父對(duì)象的依據(jù)。提問題，我想這比搞程序要簡(jiǎn)單得多，比如：顯示器能顯示多少乘多少的字符？顏色是多色還是單色？顯示模式是否支持預(yù)定的方式（如移動(dòng)、閃爍等）？工作模式是圖像還是字符？等等，這里附加說明一下，對(duì)于顯示模式，我們這里都以字符顯示為例，既然是面向?qū)ο蟮乃枷耄嘈艛U(kuò)充出圖像顯示模式，還是很容易的事情。

有問題出來了，我們就繼續(xù)為它添加代碼好了。

dispGetMaxCol();//取一行最多有多少列
dispGetMaxRow();//取顯示器一共有多少行
dispGetMaxColors();//取顯示器最多有多少色
dispSetShowMode();//設(shè)置顯示的方式，對(duì)于不支持的顯示方式就自動(dòng)轉(zhuǎn)為正常顯示
dispSetWorkMode();//設(shè)置工作模式，如果沒有的模式就返回0，支持的就返回1

對(duì)于這些函數(shù)的定義，各人可以根據(jù)自己的習(xí)慣來設(shè)置，我只是臨時(shí)弄了這個(gè)例子，未必就是最好的，我的目的是重在說明思想。我也害怕把程序弄得龐大了，出本書都嫌厚。

似乎加了這些函數(shù)之后，我們根本就沒看到顯示數(shù)據(jù)的具體形式，和前面的函數(shù)一起，都并沒有什么明確的說法。這種感覺很正確，我們確實(shí)沒有對(duì)顯存做任何定義，但是似乎功能卻都已經(jīng)定義了，其實(shí)也確實(shí)是定義了，而且將來我們就這樣用，而且也不用怕，程序一定會(huì)寫完的。

五、數(shù)據(jù)傳遞與程序邏輯同等重要

繼續(xù)上面討論的問題。前面我們提到，為了使用dispShowAChar()、dispShowALine()、dispMainThread()這三個(gè)函數(shù)，我們又引出五個(gè)新的函數(shù)來，這些新的函數(shù)最主要的目標(biāo)，就是要實(shí)現(xiàn)調(diào)用者與被調(diào)用者之間數(shù)據(jù)的傳遞。

對(duì)于程序設(shè)計(jì)來講，數(shù)據(jù)傳遞與程序邏輯有著同樣重要的地位，前者經(jīng)常在最后會(huì)形成一種協(xié)議，后者則經(jīng)常表現(xiàn)為各種算法。

在裸程序中，我們的思想應(yīng)該主要是表現(xiàn)為一種靈魂，而不能如C++那樣，去追求語法的完美，所以對(duì)于參數(shù)的傳遞，我們不能去追求語法上的完美，而是不拘一格用傳遞。除了函數(shù)可以傳遞數(shù)據(jù)外，直接調(diào)用值也是一種很快捷的方式，但是調(diào)用不能隨便說調(diào)就調(diào)，而是也要學(xué)習(xí)C++上語法的習(xí)慣，盡量不能讓一些專用的變量名稱，出現(xiàn)在與專用變量無關(guān)的程序體中。例如，我們的設(shè)計(jì)中規(guī)定，我們這套裸系統(tǒng)對(duì)顯示器最多支持65536色，那么我們就會(huì)用一個(gè)16位的無符號(hào)整數(shù)來保存這個(gè)指標(biāo)。為了簡(jiǎn)化以后的說明，我們先定義兩個(gè)數(shù)據(jù)類型：

typedefunsignedintUINT;
typedefunsignedcharUCH;

如果我們用函數(shù)來傳遞這項(xiàng)數(shù)據(jù)，我們可以用如下的方式：

#defineMonitor01_MaxColors0xFFFF

對(duì)于顏色調(diào)用函數(shù)則定義如下：

UINTdispGetMaxColors()
{
returnMonitor01_MaxColors;
}

很顯然，如果另一個(gè)顯示器是個(gè)單色顯示器，則顏色調(diào)用函數(shù)只需要改為下列形式就可以了：

#defineMonitor02_MaxColors0x0001
UINTdispGetMaxColors（）
{
returnMonitor02_MaxColors;
}

之前有人提到過，用數(shù)組，這可以解決很多問題。說得一點(diǎn)沒錯(cuò)！上面的例子我們忽略了一個(gè)問題，那就是同一個(gè)函數(shù)名要去做很多不同函數(shù)所做的事情，而我們卻沒有在函數(shù)體內(nèi)使用switch()，這顯然是不對(duì)的。要真正實(shí)現(xiàn)不同顯示器的共同屬性MaxColors的傳遞，我們必須要添加switch()以區(qū)分不同的顯示器類型。那么這里我們就需要引入一個(gè)新的父對(duì)象屬性以指代它的第幾號(hào)兒子：

UCHMonitorType=0;//顯示器類型，最多支持256種顯示器

并在初始化的時(shí)候，為該屬性初始化為0，以作為缺省類型顯示器的代號(hào)。以下命名我們就說一個(gè)約定，以讓代碼更具有規(guī)范的模樣：父對(duì)象的接口函數(shù)用小寫的disp打頭，變量用Monitor打頭，宏數(shù)據(jù)用Monitor開頭并且內(nèi)部至少有一個(gè)下劃線，宏函數(shù)則用全大寫字母組成。那么不用數(shù)組的情況下，上面的代碼將會(huì)變成如下形式：

#defineMonitor_000
#defineMonitor_011
#defineMonitor_022
UINTdispGetMaxColors（）
{
//以下用多出口，但這并不會(huì)破壞什么，為節(jié)約代碼，完全可以使用
switch（MonitorType）
{
caseMonitor_01:returnMonitor01_MaxColors;
caseMonitor_02:returnMonitor02_MaxColors;
}
returnMonitor00_MaxColors;//缺省則返回默認(rèn)顯示器
}

這樣的形式很顯然是太冗長(zhǎng)了，盡管非常結(jié)構(gòu)化，但是一般在優(yōu)化程序的時(shí)候我們還是可能會(huì)廢棄它的，所以這里就提到了數(shù)組的使用。既然是數(shù)組，那么它自然不能屬于某一個(gè)子對(duì)象，而是應(yīng)該在父對(duì)象中定義的，盡管這樣做我們每次在添加新顯示器的時(shí)候我們比如在父對(duì)象中添加難以理解的新的數(shù)據(jù)，但是為了節(jié)省代碼，我們還是能忍受這樣的痛苦。如果改用數(shù)組，則上面的代碼將改變?yōu)槿缦滦问剑?/p>

#defineMax_Monitor_Types3***
#defineMonitor00_MaxColors1
UINTcodeMonitorMaxColorsArray［Max_Monitor_Types］=
{
Monitor00_MaxColors，//缺省為單色
Monitor01_MaxColors，
Monitor02_MaxColors，
};***

打***的語句將是未來擴(kuò)充時(shí)不斷需要修改的句子。那么上面的函數(shù)就簡(jiǎn)單了

UINTdispGetMaxColors（）
{
returnMonitorMaxColorsArray［MonitorType］;
}

甚至有人還可以用宏函數(shù)來節(jié)省運(yùn)行時(shí)間，只要修改一下調(diào)用規(guī)則就可以了：

#defineDISPGETMAXCOLORS(c)c=MonitorMaxColorsArray［MonitorType］;

也許當(dāng)我們寫成如上代碼的時(shí)候，我們的每一次改進(jìn)，都會(huì)讓我們欣喜，我們的代碼又優(yōu)化了。但是可惜的是，這種沒有思想的優(yōu)化會(huì)在不遠(yuǎn)的將來，給我們帶來麻煩。我覺得我的記憶力很不好，也許一分鐘前的事情我都會(huì)想不起來，這種在將來擴(kuò)充中的上竄下跳地修改會(huì)讓我覺得暈眩！

所以，在工程化的工作中，我們需要把父對(duì)象與子對(duì)象盡量隔離開來，減少關(guān)聯(lián)性的修改量，這也是面向?qū)ο笏枷氲闹匾饬x之所在，對(duì)于這一改動(dòng)，我將在下帖中闡述。

六、父子對(duì)象接口函數(shù)功能剝離

上文我們說到dispGetMaxColors()的一些設(shè)計(jì)思路，我們有很多很好的辦法來實(shí)現(xiàn)它，但是我們有沒有更好的管理辦法來實(shí)現(xiàn)它，這才是我們要站在更高層次看問題的焦點(diǎn)，是更重要的。這也就是一個(gè)從傳統(tǒng)思維到面向?qū)ο笏季S的一個(gè)重要的轉(zhuǎn)折。

要想把這個(gè)函數(shù)轉(zhuǎn)變?yōu)槊嫦驅(qū)ο蟮倪壿嫿Y(jié)構(gòu)，我們也要先做些準(zhǔn)備工作。

第一說參數(shù)傳遞的思想。盡量減少參數(shù)傳遞，這是尊重C51系列8位單片機(jī)硬件現(xiàn)狀的一項(xiàng)重要措施，記著，不要抱怨C51檔次低，資源少，而是要在尊重和熱愛C51的前提下，我們才有熱情來發(fā)展我們的裸程序面向?qū)ο笏枷氲模簿褪钦f，無論我們面臨的系統(tǒng)有多簡(jiǎn)陋，我們都有策略，來實(shí)現(xiàn)復(fù)雜的功能，而且從發(fā)展的眼光來看，產(chǎn)品的升級(jí)，并不是盲目的升級(jí)我的CPU，因?yàn)槟菢又粫?huì)讓產(chǎn)品設(shè)計(jì)者智商下降，所以我覺得C51的特色就是應(yīng)該在簡(jiǎn)潔，越來越簡(jiǎn)潔，而不是越來越復(fù)雜。所以我希望我們把思想升級(jí)作為升級(jí)產(chǎn)品的一個(gè)發(fā)展方向。傳遞參數(shù)要減少指針、浮點(diǎn)等類型的數(shù)據(jù)傳遞，盡量以UCH與UINT為主，而且參數(shù)的數(shù)量不要太多，最理想的上限是2個(gè)，如果實(shí)在多了，就使用共享緩沖區(qū)，或者全局變量。最好是不要傳遞參數(shù)。

本函數(shù)就利用了MonitorType省略了一個(gè)參數(shù)傳遞。

第二是我們要讓父對(duì)象的接口函數(shù)與具體的子對(duì)象的多種可能性的功能實(shí)現(xiàn)剝離，這里我們就需要使用函數(shù)指針。函數(shù)指針也許我們一般用得少，但是其實(shí)并不是很復(fù)雜。先看我們函數(shù)的形式：

UINTdispGetMaxColors(void);

為該函數(shù)定義一個(gè)指針類型，只需做如下定義，就可以了：

typedefUINT(*dGMC)(void);

那么對(duì)于父對(duì)象中的dispGetMaxColors()函數(shù)，我們就只需要轉(zhuǎn)換定義一個(gè)函數(shù)指針，在創(chuàng)建父對(duì)象的時(shí)候?yàn)樗峁┮粋€(gè)子對(duì)象對(duì)應(yīng)功能調(diào)用的入口地址，就足夠了。所以對(duì)于這個(gè)函數(shù)的實(shí)體將只在子對(duì)象中出現(xiàn)，而在父對(duì)象中只會(huì)出現(xiàn)一個(gè)變量的定義：

dGMCdispGetMaxColors;

為了給它賦初值，我們也可以定義一個(gè)空指針，作為一個(gè)未使用的判斷標(biāo)志：

#defineNIL0

那么初始化dispGetMaxColors的時(shí)候只需要寫條如下語句就可以了：

dispGetMaxColors=NIL;

而且功能調(diào)用也很簡(jiǎn)單，與實(shí)質(zhì)的函數(shù)是一樣的：

if(dispGetMaxColors！=NIL) vMaxColors=dispGetMaxColors();

如果再加上約定，連前面的判斷語句完全可以省略。因?yàn)槲覀兊穆愠绦虻某绦蚩臻g實(shí)際上也是運(yùn)行空間，不存在代碼調(diào)入內(nèi)存和移出內(nèi)存的事情發(fā)生，所以我們不需要考慮程序內(nèi)存的優(yōu)化問題，只要我們規(guī)定對(duì)象一定是先創(chuàng)建后使用，判斷語句就會(huì)變得沒有意義，而且我們創(chuàng)建后即使不再使用，函數(shù)體我們也不會(huì)釋放，因?yàn)樗环旁诔绦蚩臻g內(nèi)是固定死的，你想移出去，還不能實(shí)現(xiàn)呢。

第三，盡量讓程序所使用的語法簡(jiǎn)單化，以減少編譯器可能帶來的差別而產(chǎn)生的理解上的誤區(qū)。有人說C51是C的子集，這說法我認(rèn)為不科學(xué)，只能說二者繼承了C的基本精神，而在實(shí)質(zhì)上它們針對(duì)的是不同的對(duì)象，所以也出現(xiàn)了一些不同的結(jié)果，所以我看到有些高手或者一些面試題弄出一些題目來讓我望而生畏，也許我做一輩子的裸程序也做不出他們的題目，但是我并不覺得我不如他們。他們只不過是在編譯器上花了很多時(shí)間研究他們的一些約定，而我并不想花時(shí)間去研究那些將來可能發(fā)生變化的東西，我希望我能用一個(gè)更簡(jiǎn)單的途徑把我的事情做出色，我只關(guān)心我的項(xiàng)目的速度、代碼的大小、運(yùn)行的效率、維護(hù)的復(fù)雜度，所以我也建議和我交流的人能用一種通俗的方法來實(shí)現(xiàn)我們的功能，也不必過多的考慮我的程序在8位單片機(jī)上可以用16位單片機(jī)上也可以用，我們的系統(tǒng)要經(jīng)常升級(jí)，但不要輕易去增加硬件成本。當(dāng)然如果你有精力去研究那些約定，也沒什么，只要你樂意。

好了，上面三條，只有第二條是我要說的關(guān)鍵，其他兩條，個(gè)人可以根據(jù)自己的具體情況來尋找一些快捷實(shí)用的方法。其實(shí)說來我們把父對(duì)象用函數(shù)指針來代替實(shí)體函數(shù)，這完全是一種思想，我們并沒有使用復(fù)雜的語法，而是從管理上把對(duì)象分離開來，讓不同的人做不同的事情，比較容易。但是同時(shí)我們又不能讓這種中間環(huán)節(jié)影響我們程序的效率，所以我們完全可以自己尋求一些方法，而不必去循規(guī)蹈矩。我這樣說也許會(huì)遭到一些非議，但是我可以告訴大家，計(jì)算機(jī)語言這門學(xué)科，本身就是一門人造科學(xué)，沒有最好只有更好，我們沒必要完全按照別人的思路去發(fā)展設(shè)計(jì)思想，所以也不要拿著人家的一些約定來引以為榮，那些東西，只有先學(xué)后學(xué)的問題，沒有水平的差異；我們應(yīng)該更注意的是，人家創(chuàng)造了工具，我們就用工具再來創(chuàng)造世界！如果你停留在欣賞工具的層次上，那就是無所鳥事了！

本帖實(shí)質(zhì)上只說了一個(gè)轉(zhuǎn)換，兩條建議，這都不是具體的程序，而是思想。我想強(qiáng)調(diào)的，也不是格式，而是思想。下帖將再回到對(duì)象上，和大家探討一下對(duì)象本身的組織問題，比如對(duì)象的層次關(guān)系、對(duì)象的創(chuàng)建、對(duì)象的書寫等等，我也希望有人能有一些更好的方法回到帖子里，我們互相學(xué)習(xí)，共同提高。

七、面向?qū)ο笏枷氲膶哟侮P(guān)系

前面的思想衍變過程已經(jīng)說了很久了，面向?qū)ο蟮乃枷胍簿偷搅斯鲜斓俾浜糁龅木辰缌恕Ｏ旅嫖揖拖葓D示一下裸程序設(shè)計(jì)中面向?qū)ο笏枷氲膶哟侮P(guān)系：

相信這張圖已經(jīng)足夠說清楚我們?cè)贙eilC中如何用語言來組織我們的顯示器對(duì)象disp了。disp是一個(gè)抽象的對(duì)象，它只是一種聯(lián)系，完成對(duì)所有子對(duì)象d000、d001、d002到最多d255的歸納概括并提供一組被調(diào)用者所使用的功能接口。這些功能接口正是上貼所提到的函數(shù)指針。而具體的功能實(shí)現(xiàn)及不同顯示對(duì)象對(duì)數(shù)據(jù)結(jié)構(gòu)的要求，我們都可以交給子對(duì)象設(shè)計(jì)工程師自己去決定。

很顯然，大家在這套方案具體的程序設(shè)計(jì)過程中，最主要的精力還是要放在自己做自己的問題上，多思考如何把事情做得更漂亮，而不必在代碼編寫時(shí)黏糊不清。父對(duì)象設(shè)計(jì)者必須要完成總體方案的設(shè)計(jì)，抽象思維多而具體工作量少，子對(duì)象的設(shè)計(jì)者則恰恰相反，只需要多考慮考慮具體的設(shè)計(jì)，而不必去擔(dān)心別人是怎么用自己的東西。

很顯然，作為總體設(shè)計(jì)者，必須要嚴(yán)格考慮這中間的數(shù)據(jù)交換關(guān)系，因?yàn)槲覀儧]有操作系統(tǒng)，所以對(duì)于可用的內(nèi)存資源的使用法則，直接關(guān)系到我們整個(gè)系統(tǒng)的成敗，混亂使用常常會(huì)導(dǎo)致系統(tǒng)崩潰，相對(duì)獨(dú)立的代碼則在編譯過程中由KeilC直接安排好了，我們不需要去考慮它們對(duì)程序的影響。

例子中的顯存大小及顯存的位置都是我們方案成敗的關(guān)鍵。我們都知道KeilC對(duì)單片機(jī)內(nèi)存劃分了四種，即data、idata、pdata、xdata四種，各種存儲(chǔ)器的大小與特點(diǎn)都決定著我們代碼的運(yùn)行效果，我們既要考慮信息所需要的空間，又要考慮單片機(jī)處理時(shí)足夠達(dá)到我們的視覺要求。在這個(gè)例子中，我覺得我們可以選擇xdata來作為顯存。為什么呢？

因?yàn)槲矣X得只要我們處理得當(dāng)，我們的單片機(jī)完全可以克服處理速度上的缺陷，所以我們可以優(yōu)先滿足信息量的要求，提供足夠多的空間來實(shí)現(xiàn)我們想要的功能。

提速的方式有很多，比如：選擇一些性能優(yōu)越的新型單片機(jī)，傳統(tǒng)的是12T的，現(xiàn)在有6T的，也有1T的，這讓很多指令都會(huì)有更高的效率；適當(dāng)?shù)奶岣呔д耦l率；選擇更科學(xué)的算法；等等。

到目前為止，基本上可以去構(gòu)造我們的對(duì)象了，如果你有興趣，你可以使用#define進(jìn)行一些偽碼定義，把我們的對(duì)象定義得更美觀一點(diǎn)，更接近C++一些，不過我要說的是：我們這里沒有嚴(yán)格的類定義，所以定義時(shí)類與對(duì)象經(jīng)常是沒有界限的。