Z07 Root(1)──最根本的的Interface

●ObjectInterface

我的程式碼處理工具將只針對自己定義的寫作規格處理，這是因為所有人的程式寫作風格都不相同，遇到一對多的定義時工具完全無法作任何判斷。最快區分程式碼是否符合規定格式的作法，就是定義一個介面來判斷。另外，在[M09]與[M10]定義過所有物件最基本的行為：生成與消滅，這兩個方法就是放在這個最根本的Interface。

在我的程式世界裡，將會有事與物兩大類。物件不會直接繼承或實作ObjectInterface，而會根據它是事或物的特性來繼承ProcessObjectInterface或是DataObjectInterface：

●ProcessObjectInterface

對於事的定義多了兩個狀態：開始處理與停止處理，也就是把[T13]裡的initial()與dispose()狀態拉到這裡成為startProcess()與stopProcess()。如此一來，所有屬於事的物件就擁有生成、開始處理、結束處理與消滅四個基本行為，這是根據一個機制要開始做事與停止做事所定義出來的時間點。

util套件內的所有程式都會實作這個介面。

●DataObjectInterface

可以盛裝值是物的特性，每一個物應該提供的共通行為是setValue()、getValue()與removeValue()。對於所有的物而言，最單純的物就是只放置一個value。

這個介面未來會延伸到基本Data Model再擴充使用。

Y14 設計想法彙總(4)──事時物者為俊傑

[W02]裡的人、事、時、地、物五個元素，其中人與地偏向於能否運行的條件的定義，真正達成功能的要素還是在“於特定的時間點發生指定的事以影響對應的物”，因而古有明言：事、時、物者，為俊傑。（這……真是夠冷）

程式的執行的最終結果是為了操作資料，部分的人會將設計重心放在資料的存取，而我認同是事的處理過程才去影響到物，所以將設計的重心放在如何以人性的思考來鋪陳事的經過以及事如何去操作物，還有如何將事掛到對應的觸發時間點上。我們時常聽到“堅持做對的事”，這句話其實很適合運用在設計事的處理過程，再加上“所有的物只被事所影響”的限制，“堅持做對的事，同時讓影響的物合乎規範”就形成我最根本的設計理念。再多思考一下會發現，事隱含有處理流程（Flow）與分解動作（Action）二種元素，Action是真正做事的行為，Flow則是組合Action達成目標的完整經過，將兩者明確地分離對於動態置換有相當大的助益。

在程式設計領域裡有很多人提供非常有用的想法與工具（譬如最近亂翻過的新書──編程創藝：編寫出卓越的程式碼就寫得相當好），但是實在不希望程式設計永遠是那種不同人寫的不同、同一個人不同時間寫的也不同的那種混亂。我的目標是想擺脫“趕快用程式碼堆砌出功能就對了”這種思維的產出，而從順應事物運行的自然流動作為出發點來設計。事（Flow、Action）與物（Model）是元件結構裡的三個重要部分，希望只需要簡短的說明就能讓大部分的人寫出相同規格的程式碼。

要去布置妥程式碼會花較多時間，絕對沒有人會接受多花時間只能得到相同運行結果的，現今有些作法有令人頭痛的關聯追溯與文件問題，推論起來有機會在我的理念中全部自動產生；目前唯有讓自動產生內容節省的時間大於（大很多）布置程式碼時多用的時間才會有誘因。

科學的字義是：以一定對象為研究範圍，依據實驗與邏輯推理，求得統一、確實的客觀規律和真理。精確地100%維持每一個程式指令全部在對的位置做著對的事是極其困難的，需要團隊中每一位成員的堅持。暫且放下類似“人性不可能做到100%”的負面想法，試著思考“怎麼調整可以達成那個理想？”、“做到後是否真的帶來那些好處？”，積極地相信未來的願景才有可能在現下勉勵自己達成各項要求一步步的前進……。

註：努力的方向（[Q09]、[Q10]、[Q11]、[Q12]、[Q13]、[Q14]、[Q15]、[Q16]、[Q17]與[Q18]）記錄的是我想做的。

Y13 設計想法彙總(3)──唯一的資料物件

在執行的過程中模組與元件都各自操作自己的資料物件，在設計時會根據不同的需要定義存取方法，不過我想做的是在各自的資料物件包裝內全部使用一種實作──基本Data Model。

基本Data Model向下可以使用不同的Parser對應各多種儲存檔案：目前實作過XML、properties、text、CSV、excel，計畫再對應html、ResultSet、Model（使用XML字串描述而生成定義的物件種類）以符合更多樣化的運用；Parser應該提供這幾個基本功能：讀檔、存檔、傳入字串與傳出字串。再者就是能夠以對應基本Data Model的單一編輯器達到通用的目的。



向上則可以被繼承後依照個別的需要定義存取方法，宣告為元件結構裡的Model、Properties與Exception。另外，為了區分每種資訊被存取的差別，會要求必須擁有獨自的getter與setter，不得使用通用型的方法。

在執行期間只要更換Properties的內容（或是重新設置），就能夠改變元件內部的行為；不同模組或元件之間的資料傳遞也只需要取得基本Data Model字串再直接傳到另一處而變得簡單。如果需要當時資料物件的全部內容，經由Parser可以轉換為各種不同格式的字串寫在log裡，事後可輕易地回復為該時間點的執行資料進行測試。

在公司曾實作過一版最早版本，幾位用過的同事都覺得方便且容易操作，自己也滿意這樣的設計結果。雖然基本型態的欄位資料都必須使用String型態存放，但是在不甚計較容量與速度的執行環境下卻也沒有什麼缺陷。

與基本Data Model想法有關的文章是：[C22]、[E06]、[E07]、[E08]、[E09]、[E10]、[E11]與[E12]。

Y12 設計想法彙總(2)──遞迴的一致結構

規畫好放置框架後，接下來思考的是：現在每個模組與元件都只有近似的結構與寫法，有沒有可能定義出“完全一致”的適用規格？如果定義得出來，就可以把程式碼視為一種格式化的文字檔，撰寫很多工具程式來自動處理這些檔案內容。

根據這個目標，我認為需要的就是一致的元件結構與元件間的遞迴式呼叫。

元件結構的一致性，在[D06]、[D07]、[D08]、[D09]與[D11]有詳細提到切割的六個部分：
●Implementation
　管理元件內部的小型工廠與使用窗口。元件生成後，內部Flow與Action的生成與置換都由它處理；另外每一個介面方法必定要通過這裡的管理。（整個元件的生成應由元件生產工廠模組來統一管理）
●Flow
　元件內部處理流程統一放置的類別。應依照SOP的想法定義每一個方法的實作流程，在不同應用的需求下允許使用者動態改變流程類別。
●Aciton
　操作流程分解動作統一放置的類別。流程依照SOP的想法定義，流程中的每一個步驟都定義在這裡，在不同應用的需求下允許使用者動態改變動作類別。
●Model
　定義元件專用的資料類別。每一個屬性都要同時提供getter與setter。
●Properties
　定義預設生成的Flow與Action，以及其他執行期間需要調整的參數。由Implementation讀入並保留使用。
●Exception
　每個元件要有自己的例外。介面方法內部發生無法預期或難以處理的情況時，拋出內含相關資訊的例外物件。



完美地保持只呼叫下一層的遞迴型態，代表著需要嚴謹地定義每個套件的使用關聯，並補齊每一個層次原本沒有定義的元件空隙；只要有一個例外，就會造成處理程式的邏輯判斷錯誤。當然，也必須讓處理程式知道每個層次的定義與存取位置。自動產生設計文件的記錄在[P06]、[P07]、[P08]、[P09]與[P13]。

當元件結構的一致性與從上而下的遞迴規則定義好之後，可將足以得到很多現在難以自動產生分析、統計、追溯……以及各種想像得到的程式內容應用。

Y11 設計想法彙總(1)──層次與使用定義

這陣子會去思索至今為止我想做出來的設計到底是什麼？能否整理清楚並明確地傳達給別人？是否有足夠的理由與好處去說服周邊的人承受較多的不便去遵循？這些都盤踞在我的心裡。

首先是關於層次的設定，像下圖中這樣Business Module、Module、Component、Utility從上到下佈置下來的方式，雖然安排的層次上或多或少有所不同，但是由上到下的使用關係都是大家所習慣的作法。這裡我想要討論的是：需要開發電子日誌商業模組時決定要使用外面開發的DB存取元件，應該直接從電子日誌模組使用？或是定義一個自有的DB存取元件使用，電子日誌模組只呼叫它呢？（如果只看功能，程式怎麼布置都可以達成）



最快的方式是在電子日誌模組裡直接使用外部的DB存取元件，這意味著模組與外部元件有不可分的相依性，所幸這個問題在遇到第二種資料庫時就會因為想要抽換實作層而自己布置一個Component來負責。再接著會遇到一些通用機制需要設計（像是roll back、SQL command管理等），那些是所有使用DB的商業模組必須應用的，但是若想放在功能性強的Component又會感覺綁手綁腳的。



從上方往下看是這張圖中像洋蔥的結構，Use Case劇本呼叫的是Business Module的方法，再一層層地向內使用，外部元件全部由Component包在其內部使用，在其他任何層次都不會接觸到。在這種結構下，與外部的接觸點只限於Component層（Utility也可能會使用到外部Class），可以避免在任何模組或元件都能使用外部元件。

一致的層次設定與使用規則，是最開始就需要定義好的布置框架。

X13 簡單幽默之範例(1)──蚊子

以下內容一字未改，均為當時打字的記錄。

[同事]　蚊子是令人髮指的生物
Joying　蚊子.....正是夜晚穿梭我們"髮"際, 死於我們"指"間的......
[同事]　是半夜咬我們的害蟲
Joying　我家最近也很多
Joying　常常半夜起來, 臉上都一陣酥麻......
[同事]　感覺天氣回溫 害蟲就多了
[同事]　我每天半夜都被蚊子叮醒 睡眠不足
Joying　唉......
Joying　我看, 我們去買一個以往罩在餐桌上防蒼蠅的那種罩子
Joying　調整一下, 睡覺時罩在臉上吧
[同事]　去
[同事]　買蚊帳還差不多
Joying　嘿, 你想出好解法了 :)
[同事]　我昨天睡前 用電聞香薰過房間了 還是沒用
Joying　不然本想再建議西洋劍的面罩....
[同事]　你先試試好了
Joying　我曾幻想過
Joying　有沒有辦法睡覺時把捕蚊燈佈置在頭的周圍.....
Joying　像是把燈泡拿掉, 換成頭在裡面
Joying　這樣蚊子一過來就會先被電
[同事]　這...
Joying　不過, 所有人都認為, 頭會先被電焦　
[同事]　應該會
[同事]　翻身時就身亡了
Joying　好可惜, 那是最棒的解法說, 但有技術瓶頸沒法克服 :(
[同事]　最棒的解法應該適用蚊帳比較好吧
Joying　也有蚊帳裡飛進蚊子的bug啊
[同事]　而且就算蚊子飛到蚊帳裡 範圍也比較小 一下子就抓到了
Joying　呣....只好先選用這囉
[同事]　我個人是不愛蚊帳
Joying　也還有另一個方式喔.....只要讓房間比外面冷, 蚊子自然會待在外頭 (自然驅蚊法)
[同事]　這點我想過 很難　
[同事]　除非開冷氣
Joying　會被當瘋子吧 =.=
Joying　牆角放幾塊大冰塊還比較可行
[同事]　那才會被當瘋子
Joying　至少外人不知道啊.....開冷氣, 全街都知道你瘋了.....
[同事]　切

Z06 工作計畫(1)──第一階段（root）

依據腦海裡的最終目標，先切分可以逐步實現的小目標，再先根據各個功能的相依性定義出root專案應該要達成的工作項目：

●所有程式必須實作的Interface
原先只定義ObjectInterface，為了區分根本的事與物而再衍伸了ProcessObjectInterface、DataObjectInterface。兩者都繼承自ObjectInterface，處理資料的程式實作前者，放置資料（尤其是各種DataModel）實作後者。

●基本物件與工具程式套件
先布置一個util套件來放置所有純粹處理各類資料用（內部不放置任何資料的那種）的程式，像是StringUtil、ArrayUtil……等；另外還有object套件來放置與資料相關的程式，像是ListMap、StringTokennizerNew……等。

●定義Component的規格
這裡會定義Component的最初型態，目前定義了兩種：第一種是標準Component，會有Impl、Flow、Action、Properties、Data與Exception六個部分，主要目的是可以任意更換Flow或Action或Data；另一種是簡單Component，不會有Impl，Flow與Action合併於一支程式（方法需加annotation識別），Data可定義於外面也可藏於內部。

●基本Log元件記錄是追蹤與分析，因此log元件是第一個要製作的元件。這裡要做出的是可以記錄的機制，透過同一組介面讓記錄可以依設定選擇要記錄在console或者是檔案。

●基本Data Model + Parser
第一個要做的元件，因為未來所有模組與元件唯一繼承使用的資料物件。支援檔案種類暫時規畫有XML、Properties、Text、CSV、Excel這幾個原有的，在後面的階段會延伸到Java File解析的系列。

Z05 版權宣告與註解範本的內容

撰寫程式碼除了code本身之外，每一支程式都必須要有的部分就是版權宣告與程式碼註解。每支程式最前端都會有我自己的版權宣告段落：

/*******************************************************************************
* Copyright (c) 2010 Joying Lee
*
* All rights reserved.
* This program is free to use, but the ban on selling behavior.
* Modify the program must keep all the original text description,
* and can only comment out the original code (not allowed to delete).
*
* 保留所有權利。
* 本程式可任意使用，但是禁止販售行為。
* 修改程式時必須保留所有原有文字說明，而且只能註解掉原來的程式碼 (不允許刪除)。
*
* My Blog : http://ooadreason.blogspot.com
*******************************************************************************/

註解的定義根據[V01]的描述，區分為Class、Field與Method三種；註解的本體目前定義有摘要、描述與使用三個部分，再往下則是@開頭的Java Doc常用標籤。整理為出一份自己要使用的關係對照表如下圖，接著遵循這些註解規則建立Eclipse內的Code Template並匯出XML作為往後使用的標準。



最後定義程式中描述處理過程的註解與變更時與Trac ticket相關的標記註解如下：

/* 這是描述處理過程的註解，必須獨立存在一行 */
// 這是與Trac ticket相關的標記註解，必須在程式碼那行的最後面

註：在以下範例程式的三個註解位置，似乎各自代表不同的意義。我的解讀是：
註解Ａ－描述if那個指令的判斷說明。
註解Ｂ－描述if成立後那個block的說明。
註解Ｃ－描述return那行的說明。
/* 註解A */
if (isTrue()) /* 註解B */ {
　　/* 註解C */
　　return;
}
若依照我的註解準則與未來模組化的目的，應該變成可讀性略差的這樣：
/* 註解A */
if (isTrue())
/* 註解B */
{
　　/* 註解C */
　　return;
}

參考網址：http://java.sun.com/j2se/javadoc/writingdoccomments/index.html

Z04 工欲善其事，必先利其器

新的年度開始，也該是進入新階段的時候。俗話說的好：工欲善其事，必先利其器，這句話的意思是說只要讓別人看到自己在準備工具，就會以為你要開始做事。咦？解釋的角度不對？總之，不管要不要做事，先把工具弄好就對了。

前陣子研讀Java Power Tool的經驗，剛好可以移植需要的部分到自己的開發環境。先列出必須要在Windows環境下安裝的應用程式：

●StarUML 5.0　下載網址：http://staruml.sourceforge.net/en/download.php
　Rational Rose不是每個人都有，還是使用免費軟體比較適合；這是我覺得比較適用的。
●JDK 6 Update 18　下載網址：http://java.sun.com/javase/downloads/widget/jdk6.jsp
　使用Java SE就能符合近期的需要。
●Eclipse 3.5.1　下載網址：http://www.eclipse.org/downloads/
　下載Java EE的版本。本來考慮用Modeling版本來畫UML，但是現在設計與開發還沒有很好的串接；也考慮使用可以開發plugin的Standard版本，這等到需要開發plugin工具時再說吧。
●VisualSVN 1.7.7　下載網址：http://www.visualsvn.com/visualsvn/download/
　Windows環境下很方便使用的SVN Server，安裝後可立即開始使用。暫時還不會用到版本控管，不過還是一起安裝。

以下是我在Eclipse裡安裝的plugin（在Eclipse上安裝plugin的方法請上網搜尋）：

●Subversive 0.7.8　安裝網址：http://download.eclipse.org/technology/subversive/0.7/update-site/
　版本控管的Client端。暫時還不會用到。
●Subversive Connector　選擇SVN Kit 3.0後會自動開始安裝。
●M2Eclipse 3.0.0　安裝網址：http://m2eclipse.sonatype.org/update/
　管理Maven專案的工具，除了plugin設定configuration還不能用之外是很方便的工具。在我的環境裡不打算安裝library server，直接上global repository同步。
●Java Doc：內建。
●Checkstyle 5.0.3　安裝網址：http://eclipse-cs.sf.net/update/
●PMD 3.2.6　安裝網址：http://pmd.sf.net/eclipse
●Findbugs 1.3.9　安裝網址：http://findbugs.cs.umd.edu/eclipse/
　以上三項是協助檢查程式碼是否符合一些常用規則的工具軟體。
●jUnit 4：內建。
●Eclemma 1.4.3　安裝網址：http://update.eclemma.org/
　檢查Unit Test涵蓋度的工具軟體。