草稿未完

以前偶爾也想多認識一下程式語言，只是沒這此久。那時費了大半時間還沒認識Function，一時熱情早就被一堆冷變數、資料型態、數學運算、邏輯判斷早就把人弄翻了！

其次，(早期)學習新東西總要用些舉來或實務來增加理解。大部份的例子並沒有錯或不好，但是例子的範圍無形的限制了我們初期生成的觀念，一不小心沒注意到就成了進階時的障礙！那麼來吧！我們也舉例一下囉！

早先例如：變數/變量的宣告及使用，我們可以說宣告一個變量就把一個很多櫃子的拿來使用，櫃子本身在物理條件下，就好像可以看成execl這的資料表的儲存格，真的也是如此的儲存格。所以格子的最外橫向可以做編號、縱向也可做編號，使用變數就像在這些空間的使用。像這樣的例子原則上沒錯吧！也沒什麼大問題。當然問題不在那，而是我們並沒有弄懂這些存儲格的環境。

(至少現在的看法)其實我覺得，運作範圍電腦的內在實務上運作是比較「大」，因而乎略中間過程，這樣反而告成學習的障礙。也就是把乎略的中間過程補回來，思維層級自然就會前進二層，相對的反而更好理解為麼這麼做而不那麼做！

也就是說電腦這小東西，它的運作構架反而可以大到等同一個國家或縣市級的運作程度，或許用最相似的加工區及物流倉儲來說，例如：這個地上有10棟大樓、每棟10樓、每樓10個線、每線100坪？為什麼最後用100坪而不用架子呢？其實是保留一點彈性。因為這是個萬能制造工廠，有些是生產制造區，有些是倉儲區。

因此不管你做什麼這個空間己是固定，這個環境就是電腦的總體資源，硬體上的編號通常是制式的。例如棟、樓及本身的占地面及空間。當然啦！我們基本上還是會放上架子或櫃子而架子或櫃子又可放上些格子來分類。所以大體上就是如此！可是會什麼要這廢話多事呢？因為我們必需要明白，電腦運作中我們看不到的架構，這些都是OS的工作。

就如每個倉都使用同樣資料來表來紀錄存放管理資料，就如EXECL這樣的資料表，表中儲存格就可以很好識別、管理及對應到那放這10坪架上放的資料物件！但同樣的一張表如果換到鄰近的其它10坪或隔壁倉去，所對應到內容就會不一樣也不合用！

另一方面這些過程都透過管理中心的個別窗口來處理。所以同樣一個指令在每個位置的結果都是會不同。而現場也同有一組對應用窗口來服務。簡言之，我們下的每一個小小指令或動作，電腦處理都經過很複雜的對應關聯後，再簡化到我們看到。

例如：也我們會說，把左三的東西刪西，就完成了一動作。也沒說那棟、那層、那倉來做，那是因為對應窗口早已設在那相對的位置，所以不要那麼複雜。但如果指令有跨區就會有其它的互動問題，對應的層級不一樣，就有安全機制，這就是「作用域的觀念。」每個工作小組都有對外、對內、及內部管理的機制，就是要記住這件事就對。

---

物件不是物件？！

這裡順便引入物件這個東西，它不難，因為它是不是東西，基本上他是一個觀念、思法，一種思考的方式。有了它初期很痛苦，後期很強大。這些我想了好久，用我比較熟悉的領域，也許可以解釋。

我們常常用車子、房子來解釋物件是什麼，這很容易理解，但卻造成更多的障礙。為什麼是障礙呢？首先，物件就一個東西來看，有東西就有名稱。而物件本身通常又有很多物件組成，所以又可逐一的剖解好幾層的細部部件，這些還是物件。所以不同層級時，我們處理的內容也會有所不同。我想這樣的解釋都聽過N百遍了，然而依舊無法理理程序語言中的物件是什麼東西。

用個雙性這個特殊字眼也許較容理解它的特別，。

 

因為在寫程序並沒成品，更沒有物品，更該說是設計圖。就像室內設計一樣，在圖面上我們設定了很桌子、椅子、櫃子、燈、明這些物件及用什麼料質、顏色等屬性等等總設計概念圖，有了全局的架構，我們再個別局部去設計各室的空間及細節，也可設計部份元素的創新施工圖。然而些都只是一個前製而己。所以房子是物件、車子是物件、桌子是物件這些一樣也沒有出現。

物件導向我們一般是做單一小物件的細節規劃及製作流程，或是小組織的配置規劃。OP的視窗架構就是物件，而瀏覽器也是一個物件。

而Function用函數這個名稱，我是覺得很不好用，另一個「作用、功用、功能、方法」更能實現他的真正內涵。就是他是為了完成一個動作而設定。也就是連續做些事的的SOP。也就是SOP是不變的，沒有呼叫或調用它，他就不會有結果出來，然不管如何他都只是一個SOP。以物件導向來想就是物件的方法，方法依照SOP去完成一連串工作，最後會有一個結果或品。