前言 一> 本書目的。 這是一本思想層面的書，主要是向讀者展示，專業程式員是如何面向對象編程的？設計師是如何面向設計編 程的？逐步引導讀者從控制項編程到對象編程再到業務設計。 二>內容結構。 同事跟我說過一句話，所謂門坎，跨過了就是門，跨不過就是坎。在介紹本書內容之前，先帶領大家瞭解一下從拖拉控制項編程 ...
前言
一> 本書目的。
這是一本思想層面的書，主要是向讀者展示，專業程式員是如何面向對象編程的？設計師是如何面向設計編
程的？逐步引導讀者從控制項編程到對象編程再到業務設計。
二>內容結構。
同事跟我說過一句話，所謂門坎，跨過了就是門，跨不過就是坎。在介紹本書內容之前，先帶領大家瞭解一下從拖拉控制項編程到面向設計編程的過程中，究竟有哪些坎，本書的目的是帶你跨過那些坎，清楚了有哪些坎，大抵也就清楚了本書要講些什麼內容了。
大部分人將程式員分為碼農和設計師，對此我是認同的，只是，什麼是碼農，什麼是設計師，各有什麼特點，從碼農到設計師的瓶頸障礙是什麼，要如何才能突破瓶頸才能從碼農登堂入室設計師。如果回答不了這些問題，說明分類不具指導意義。如果碼農指的是拖拉控制項編程的程式員，那麼，從碼農到設計師，有兩個障礙，第一個障礙是面向對象編程，這是技能問題，第二個障礙是用面向對象的思想化解業務邏輯，這是思想問題。細心的讀者可能會發現，化解業務邏輯的工具是面向對象的思想，那麼，想要掌握業務化解是不是得先學會面向對象編程？我欣喜地告訴您，是的！而且，掌握面向對象編程不是那麼容易的一件事情。因此，根據瓶頸障礙，我將程式員分三類。
一類是業餘程式員，他們寫程式是，首先開個窗體，再拖拉控制項做好界面，再編寫代碼實現功能。他們的特點是，先做界面後寫功能。這類程式員，是業餘程式員，他們寫程式是面向過程編程。
二類是專業程式員，他們寫程式是，首先開個單元，再創建並完成功能類，最後才做窗體調用功能類中的函數或方法。他們的特點是，先寫功能後做界面。這類程式員，是專業程式員，他們寫程式是面向對象編程。
三類是設計師，他們寫程式是，首先將業務化解為對象，再設計對象之間的關係，最後交給專業程式員去實現這些類（當然也可能是自己去實現）。這類程式員，是設計師，他們寫程式是面向設計編程。
相信讀者已經看出，設計師設計的是業務邏輯，這就要求你的業務邏輯是獨立的，好比娶老婆，你要娶的女人必須是獨立的，如果她跟另一個男人如膠如漆粘在一起，你就娶她不成，就算娶成了，也是一團糟。既然程式設計要求業務邏輯獨立，那麼，如何才能獨立業務邏輯？很簡單，先寫邏輯，把整個業務的邏輯寫完了，再去做界面去調用即可。也許你會問，第二類程式員，也即專業程式員不正是這麼做的嗎？正是！所以說，你要想成長為設計師，首先必須掌握面向對象編程，先成為一個專業程式員。也正因為如此，我才提議將程式員分成三類，不管我的分類是否合理，如果你還是控制項拖拉員，想要成長為設計師，瓶頸擺在那裡，你得一一去突破。本書將帶領您，從控制項拖拉員，一步步步入程式設計的殿堂。
既然本書的目的是引領讀者從控制項拖拉員成長為設計師，相信讀者已經能猜出本書要講的內容了。從控制項拖拉員到設計師有兩個障礙，我將它稱之為兩個境界，境界一是面向對象編程，跨過了，你就是專業程式員了；境界二是面向設計編程，跨過了，你就是設計師了。至此，本書的內容也躍然紙上，一是引領讀者掌握面向對象編程；二是引領讀者掌握面向設計編程。
1> 面向對象編程
如何成為一個面向對象編程的專業程式員呢？只要看專業程式員是怎麼寫程式的即可。前面已經說過了，專業程式員寫程式，首先開個單元，再創建並完成功能類，最後才做窗體調用功能類中的函數或方法。他們的特點是，先寫功能後做界面。想成為專業程式員，你學他們就行了，寫程式時先開個單元創建個類，把要寫的功能都寫在這個類中，你就是面向對象編程的專職程式員了。好象也沒多難，是吧？
嘿嘿！所有事情都是這樣，說起來容易，做起來就那麼簡單了。舉個例來說，界面有個下拉框，用來顯示員工姓名，既然界面與實現分離了，這就要求你的實現類的函數必須把從資料庫讀到的人員名單以返回值的形式提供給界面，你的函數打算返回什麼類型給界面？想一下，是不是發現真要你做的時候就竟沒法動手？至少筆者以前就是這樣，定義好類以後，就無法動手了。
也許你會說，直接返回數據集。停！公司請你去是做事的，不是請你去挖公司牆腳的，具體內容里再跟你詳細解說。讓我直接告訴你答案好了，下拉框接收的是TStringList類（字元串列表），那你直接返回TStringList類不就結了？是的，返回一個TStringList正是下拉框所需要的，問題是，我如何才能知道下拉框需要的數據類型是TStrigList類？這才是我真正想要跟你說的。
我如何才能知道下拉框所需要的的數據類型是TStrigList類？
如果你有同事會面向對象編程，最好的方法是看他的代碼。不過，終有一天，你會接近他水平，很難再從他那學到東西。既然如此，就問一下你同事，看他的知識技能是從哪裡學來的，授人以魚，不如授人以漁。如果你認識的人裡頭沒有人會面向對象編程，沒處可學，沒處可問，沒關係，我告訴你就好了。
你要找的知識之源，叫類庫！
類庫是什麼？
對程式員而言，類庫即語言，語言即類庫。
聽說類庫是很難的？
類庫好比一片森林，我今天要做的不是帶你去伐木，而是要領著你把森林里的路熟悉下來，在你需要伐木的時候，知道在什麼地方可以找到你要找的樹木。不用怕，我們今天是游客，不是伐木工，由我來當導游，領著大家完成一趟類庫森林的冒險游行。
既然躲不過，那就勇敢面對吧！如何才能輕鬆搞懂類庫？
想要搞懂類庫，首先要知道類庫做了什麼。
類庫做了什麼？
類庫只做了一件事，製作控制項。而且，製作所有控制項的方法是一樣的。想要搞懂類庫，只要搞懂一個控制項即可。
如何搞懂一個控制項？
這個問題有點不好回答。我認為，假如給你介紹一個你從來沒見過的東西，給你看一下它的模樣，再介紹一下它的用途，最後再跟你講明白它是怎麼做出來的，你是不是對這個東西就清楚了？我個人認為這樣就能對所介紹的東西瞭然於胸了，因此，我打算從控制項的出生、長相和行為三個方面跟大家把控制項說透。
1.1>控制項的創建。雙擊工具欄控制項或者將工具攔上的控制項拖到窗體上，窗體上就有了一個控制項，這個控制項是怎麼來
的？
這個問題講的是控制項的出身，說得不那麼親和一些，就是控制項的創建。在這部分將向您展現控制項的創建過程，以及帶領您用系統API創建一個控制項，領略體驗控制項的創建過程。
1.2>控制項的樣式。每個控制項的模樣各不相同，這是怎麼做到的？
這個問題講的是控制項的長相或者說模樣，在這部分將向您介紹畫布，以及在一個空白的控制項上繪製一個您所熟悉的控制項，目的是想告訴您，控制項的模樣是繪製出來的。
1.3>控制項的消息機制。控制項為什麼能響應鍵盤和滑鼠，這是怎麼做到的？
這個問題講的是控制項的行為，試想一下，你平日經常編寫控制項的事件方法，你從來都只管寫不管調用，既然都不調用，那些事件方法為什麼會被執行呢？在這部分，將向您展現控制項是如何獲取系統消息的；控制項的消息機制是如何將系統消息傳導至你所實現的事件方法的；從控制項得到系統消息到你實現的事件方法被觸發的這個過程中，有哪些函數或方法處理了消息、這些函數或方法都做了些什麼？
至此，控制項或者說類庫於您不再神秘。同時，控制項製作，是運用面向對象編程經典中的經典，通過參悟控制項的
製作過程，你將看到並體會，你在學校所學的專業知識在這個過程中是如何被運用的。親愛的讀者，你缺的不是面
向對象的知識，缺的是沒人引領你如何去使用所學的知識。是時候脫離拖拉控制項編程了！讓我帶領大家開始面向對
象編程吧！
2> 面向設計編程
如何成為一個面向設計編程的設計師呢？只要看設計師是怎麼寫程式的即可。前面已經說過了，他們寫程式是，
首先將業務化解為對象，再設計對象之間的關係，最後交給專業程式員去實現這些類。由此可見，設計師的工作是化解業務與設計對象關係，只要掌握了業務化解與對象關係的設計，你也就是設計師了。好的！讓我們開始吧！
2.1>如何化解業務？
在講解業務化解之前，先要搞懂一個概念，什麼是業務，業務是什麼？
有人說，寫程式，寫到最後，就只有業務了。這句話我就不解釋了，總之一句話，業務是一個程式的核心與靈魂，請務必領會掌握業務的概念。
廢話少說，直接上菜。業務，即需求的邏輯部分。
我們來理解一下這句話。需求，簡單說就是功能，事實上，需求不止是功能，它還有需求產生的背景，未來可能的拓展。我們是初學者，暫且不管那麼多，先簡單地當需求就是功能來理解。在專業程式員眼裡，任何功能都是由邏輯與界面兩部分組成（做服務的例外），既然需求就是功能，而業務又是需求的邏輯部分，那就是說，業務就是功能的邏輯部分。功能，想必大家都不陌生，除非你沒寫過程式。
現在，我們已經清楚，業務，即需求的邏輯部分，也即功能的邏輯部分！一波未平一波又起，又有一個問題了，功能的邏輯是什麼？
這就要求你先理解界面。界面是做什麼的？界面只有兩個作用，一是輸入，二是輸出，簡稱為輸入輸出。輸入輸出以外的事，都是功能的邏輯。
現在清楚業務是什麼了沒有？通過剛纔的分析，我們得出一個重要的結論，業務，就是功能除去輸入輸出之外的所有事情。現在來總結一下，業務，即需求的邏輯部分，是功能除去輸入輸出之外的所有事情。請記住這句話。
搞懂了業務的概念，接下來就要開始處理業務了，該怎麼處理業務這個家伙？
我們已經知道了，業務，是功能除去輸入輸出之外的所有事情。既然是事情，那就簡單了，按通常做事的方式處理它即可。平日里，大家是怎麼做事的？這還不簡單，大事化小，小事化了。再複雜的事情，只要將它分解為一個一個小事情，小事情再分解為一個一個更小的事情，整個事情的條理不就清楚了！不知不覺，你學會了業務化解的方法了，即大事化小，小事化了，專業的說法就是，用面向對象的思想分層化解。
2.2>如何設計對象關係
我們已經將業務化解成幾個小業務了，小業務又化解為幾個更小的業務了，業務對應著類，每個小業務都對應
著各自的一個小類，每個更小的業務也對應著各自一個更小的類。這樣，我們就將業務轉化為對象了。
業務和小業務以及更小的業務之前是有關係的，這種關係叫業務邏輯，與業務對應的對象、小對象以及更小的
對象之間，要體現這種關係，這種關係叫對象之間的邏輯關係。
理論上來說，我們已經將業務邏輯轉換為對象關係了，設計任務算是完成了。但是，如果對象關係僅僅是體現
邏輯關係，從編程技能來說，這是還不夠的。那編程技能於對象關係有什麼要求呢？
從編程技能的角度來說，編程的最高境界是，不寫一句重覆代碼。如何才能不寫重覆代碼？這就要求你深刻理解繼承、多態、介面等。在此部分，我將通過對象的記憶體結構讓您從對象的物理層面理解繼承、多態、介面、虛方法、動態方法的本質，不搞清楚他們的本質，你是用不好它們的。
二> 適應對象
本書對讀者技能要求有兩點：
1> 能使用最常用的十來個控制項編程，語言不限，任意一門可視化編程語言都行。
2> 會使用數據集控制項，要求不高，只要能讀取資料庫隨意一個表中的記錄到數據集就行。
如果不具備上述兩點能力，施主，苦海無邊，回頭是岸！
