konhon

SRP 單一職責原則
        就一個類而言，應該僅有一個引起它變化的原因。

OCP 開放-封閉原則
         軟件實體(類、模塊、函數)應該可以擴展， 但不可修改。

LSP Liskov替換原則
        子類型必須能夠替換它們的基類型。

DIP 依賴倒置原則
        抽象不應該依賴于細節。細節應該依賴于抽象。

ISP 接口隔離原則
       不應該強迫客戶依賴于它們不用的方法。接口屬于客戶，不屬于它所在的類層次結構。

REP 重用發布等價原則
        重用的粒度就是發布的粒度。

CCP 共同封閉原則
         包中的所有類對于同一類性質的變化應該是共同封閉的，一個變化若對一個包產生影響，則將對該包中的所有類產生影響，而對于其他的包不造成任何影響。

CRP 共同重用原則
         一個包中的所有類應該是共同重用的。如果重用了包中的一個類，那么就要重用包中的所有類。

ADP 無環依賴原則
         朝著穩定的方向進行依賴。

SAP 穩定抽象原則
        包的抽象程度應該和其穩定程度一致。

RecordStore是已byte陣列存儲的.所以需要將整個物件序列化成byte 陣列存入紀錄倉儲，也可以從資料倉儲之中讀入一個byte 陣列，然後將其回復成原本物件內部的狀態。
在此我們要借助四個類別的協助，他們分別是：
ByteArrayOutputStream、ByteArrayInputStream、
DataOutputStream、DataInputStream。

轉換例子如下:

在MIDP 1.0 規格中，Canvas 類別裡頭定義了幾個常數，他們分
別是： KEY_NUM0 、KEY_NUM1 、KEY_NUM2 、KEY_NUM3 、KEY_NUM4 、KEY_NUM5 、KEY_NUM6 、KEY_NUM7 、KEY_ NUM8 、KEY_NUM9 、KEY_STAR、KEY_POUND 共11 個，分別代表0~9 的數字鍵、星號鍵、以及井號鍵。我們可以利用這幾個常數判定鍵盤（按鈕）事件處理函式所傳進來的keyCode，藉以了解哪個按鈕被按下了，當然，除了這些按鍵之外，其他的按鍵也會有其對應值，您必須自己嘗試找出來，但是為了可以跨平臺，建議您僅只使用這些標準的定義鍵。

為了Game 設計師的方便，MIDP 1.0 規格中，Canvas 類別裡頭定義了幾個與Game 鍵盤代碼相關的常數，他們分別是UP、DOWN、LEFT、RIGHT、FIRE、GAME_A、GAME_B、GAME_C、GAME_D。這些定義雖然很可能會和之前的定義有所重複，但是因為有了一層抽象性，在移植的時候也就方便多了。

那麼，在程式裡頭該如何處理呢? Canvas 裡頭提供了兩個函式:
1. getGameAction() ?? 傳入keyCode，函式會回傳所代表的
Game 鍵盤代碼。
用法如下：


2. getKeyCode() ?? 傳入Game 鍵盤代碼，函式會回傳所代表的
keyCode。
用法如下：
任選任何一種方法，都可以達到跨平臺的目的。

其實這是有一套規格可循的。規則如下：

1. 先比較每個Command 物件的命令型態，優先順序越高的越先出現。
在Command 物件之中共定義了八種命令型態，從優先順序最高到最低列表如下：
Command.BACK
Command.CANCEL
Command.EXIT
Command.HELP
Command.ITEM
Command.OK
Command.SCREEN
Command.STOP

2. 如果命令型態相同，就比較其優先權，設定值越低的越先出現。

3. 如果優先權相同，就以利用addCommand()加入畫面的先後順序決定。

轉載自：www.csdn.net

java程序顯示中文是大家都遇到過的問題，尤其是JAD文件的中文問題，一般都用native2ascii工具轉換，這里收藏了native2ascii工具的詳細說明：


native2ascii - Native-to-ASCII Converter
Converts a file with native-encoded characters (characters which are non-Latin 1 and non-Unicode) to one with Unicode-encoded characters. 
SYNOPSIS
native2ascii [options] [inputfile [outputfile]]

DESCRIPTION
The Java compiler and other Java tools can only process files which contain Latin-1 and/or Unicode-encoded (\udddd notation) characters. native2ascii converts files which contain other
 character encodings into files containing Latin-1 and/or Unicode-encoded charaters. 
If outputfile is omitted, standard output is used for output. If, in addition, inputfile is 
omitted, standard input is used for input. 

OPTIONS
-reverse 
Perform the reverse operation: convert a file with Latin-1 and/or Unicode encoded characters to one with native-encoded characters. 


-encoding encoding_name 
Specify the encoding name which is used by the conversion procedure. 
The default encoding is taken from System property file.encoding. 
The encoding_name string must be a string taken from the first column of the table 
below. 


-------------------------------------------------------------

Converter        Description
Class
-------------------------------------------------------------

8859_1           ISO 8859-1
8859_2           ISO 8859-2
8859_3           ISO 8859-3
8859_4           ISO 8859-4
8859_5           ISO 8859-5
8859_6           ISO 8859-6
8859_7           ISO 8859-7
8859_8           ISO 8859-8
8859_9           ISO 8859-9
Big5             Big5, Traditional Chinese
CNS11643         CNS 11643, Traditional Chinese
Cp037            USA, Canada(Bilingual, French), Netherlands,
                               Portugal, Brazil, Australia
Cp1006           IBM AIX Pakistan (Urdu)
Cp1025           IBM Multilingual Cyrillic: Bulgaria, Bosnia,
                               Herzegovinia, Macedonia(FYR)
Cp1026           IBM Latin-5, Turkey
Cp1046           IBM Open Edition US EBCDIC
Cp1097           IBM Iran(Farsi)/Persian
Cp1098           IBM Iran(Farsi)/Persian (PC)
Cp1112           IBM Latvia, Lithuania
Cp1122           IBM Estonia
Cp1123           IBM Ukraine
Cp1124           IBM AIX Ukraine
Cp1125           IBM Ukraine (PC)
Cp1250           Windows Eastern European
Cp1251           Windows Cyrillic
Cp1252           Windows Latin-1
Cp1253           Windows Greek
Cp1254           Windows Turkish
Cp1255           Windows Hebrew
Cp1256           Windows Arabic
Cp1257           Windows Baltic
Cp1258           Windows Vietnamese
Cp1381           IBM OS/2, DOS People's Republic of China (PRC)
Cp1383           IBM AIX People's Republic of China (PRC)
Cp273            IBM Austria, Germany
Cp277            IBM Denmark, Norway
Cp278            IBM Finland, Sweden
Cp280            IBM Italy
Cp284            IBM Catalan/Spain, Spanish Latin America
Cp285            IBM United Kingdom, Ireland
Cp297            IBM France
Cp33722          IBM-eucJP - Japanese (superset of 5050)
Cp420            IBM Arabic
Cp424            IBM Hebrew
Cp437            MS-DOS United States, Australia, New Zealand,
                               South Africa
Cp500            EBCDIC 500V1
Cp737            PC Greek
Cp775            PC Baltic
Cp838            IBM Thailand extended SBCS
Cp850            MS-DOS Latin-1
Cp852            MS-DOS Latin-2
Cp855            IBM Cyrillic
Cp857            IBM Turkish
Cp860            MS-DOS Portuguese
Cp861            MS-DOS Icelandic
Cp862            PC Hebrew
Cp863            MS-DOS Canadian French
Cp864            PC Arabic
Cp865            MS-DOS Nordic
Cp866            MS-DOS Russian
Cp868            MS-DOS Pakistan
Cp869            IBM Modern Greek
Cp870            IBM Multilingual Latin-2
Cp871            IBM Iceland
Cp874            IBM Thai
Cp875            IBM Greek
Cp918            IBM Pakistan(Urdu)
Cp921            IBM Latvia, Lithuania (AIX, DOS)
Cp922            IBM Estonia (AIX, DOS)
Cp930            Japanese Katakana-Kanji mixed with 4370 UDC,
                               superset of 5026
Cp933            Korean Mixed with 1880 UDC, superset of 5029
Cp935            Simplified Chinese Host mixed with 1880 UDC,
                               superset of 5031
Cp937            Traditional Chinese Host miexed with 6204 UDC,
                               superset of 5033
Cp939            Japanese Latin Kanji mixed with 4370 UDC,
                               superset of 5035
Cp942            Japanese (OS/2) superset of 932
Cp948            OS/2 Chinese (Taiwan) superset of 938
Cp949            PC Korean
Cp950            PC Chinese (Hong Kong, Taiwan)
Cp964            AIX Chinese (Taiwan)
Cp970            AIX Korean
EUCJIS           JIS, EUC Encoding, Japanese
GB2312           GB2312, EUC encoding, Simplified Chinese
GBK              GBK, Simplified Chinese
ISO2022CN        ISO 2022 CN, Chinese
ISO2022CN_CNS    CNS 11643 in ISO-2022-CN form, T. Chinese
ISO2022CN_GB     GB 2312 in ISO-2022-CN form, S. Chinese
ISO2022KR        ISO 2022 KR, Korean
JIS              JIS, Japanese
JIS0208          JIS 0208, Japanese
KOI8_R           KOI8-R, Russian
KSC5601          KS C 5601, Korean
MS874            Windows Thai
MacArabic        Macintosh Arabic
MacCentralEurope Macintosh Latin-2
MacCroatian      Macintosh Croatian
MacCyrillic      Macintosh Cyrillic
MacDingbat       Macintosh Dingbat
MacGreek         Macintosh Greek
MacHebrew        Macintosh Hebrew
MacIceland       Macintosh Iceland
MacRoman         Macintosh Roman
MacRomania       Macintosh Romania
MacSymbol        Macintosh Symbol
MacThai          Macintosh Thai
MacTurkish       Macintosh Turkish
MacUkraine       Macintosh Ukraine
SJIS             Shift-JIS, Japanese
UTF8             UTF-8


不過WTK可以直接解決JAD的中文問題：
    settings>MidLets>MidLet-1屬性改成你想要顯示的中文后重新生成JAD和JAR文件即可。

out momory 一陣天旋地轉內存又溢出了。在手機上這種痛苦經常都有，套一句俗話在手機上用內存必須勒緊褲腰帶。雖然現在pc內存上G都不奇怪,可是在手機上卻只能以K來記,可能某位同志會馬上跳出來說也有上M的，記住中國還不富大多數手機都是低端手機。寫手機程序讓我仿佛回到了dos時代（自我安慰一下那個時代也煉出了不少高手說不定我是下一個）。言歸正傳做內存優化可以歸結為以下幾種方法。代碼優化，圖片優化，第三方工具優化等…

一．代碼優化
內存會溢出肯定和代碼逃不了關系,99.99%學java的人都知道垃圾回收器是java的一大優點并據此來嘲笑C++。顯然這個特性為代碼編寫者省了不少事，但這個特性卻帶來了不少隱患。舉個例子在游戲當中經常有不同場景的切換，如從游戲邏輯退到主菜單邏輯,對游戲邏輯對象的態度很多人會選擇忘記等待垃圾回收器來收尸^_^。乍看之下似乎并無不妥垃圾回收器會來善后。實際上垃圾回收器并非實時的,它不像C++的Delete語句馬上釋放不用的內存。當從游戲邏輯切換到主菜單邏輯這時兩個對象同時存在很可能這時內存就不夠用了。讀到這里很多人會發現實際上垃圾回收器在j2me上并不怎么好用，從一個角度上來講在j2me上所有垃圾必須由手工釋放,除簡單類型以外所有對象都必須顯式地置空例如 imgs=null; 實際上java提供了一個不錯的工具用來查找內存溢出,java.lang.Runtime.freeMemory() 。它可以返回當前的剩余內存數，將它適當的安放在代碼中可以有效的監測內存使用狀況。很大一部份的j2me程序員之前都是從事pc軟件開發工作，充裕的內存掩蓋了許多寫代碼的不良習慣。如下所示:
//a 不為空
a=new Logic();
很多人可能對此有異議，他們會認為新的對象會把舊的對象沖掉并且釋放內存。這里面包含兩個問題：1. 該段代碼是先創建對象然后再進行賦值操作的，也就是說在這期間有兩個對象同時存在這就很可能會產生溢出。2. 這樣做也會妨礙垃圾回收器的工作
較好的寫法如下:
a=null;
a=new Logic();
雖然麻煩了點但在j2me中還是必要的。接著看下例。
drawString("游戲時間:" + time ,50,50,Graphics.LEFT|Graphics.TOP);
"游戲時間:" + time 很完美在paint()方法當中每次都被刷一遍顯示在屏幕上。危機往往隱藏在美麗的外表，該語句會引起新的內存重新分配來存儲 "游戲時間:" + time 而顯示完以后又必須由垃圾回收器釋放，用了雙倍時間,并且容易發生內存溢出。依此類推在重復執行的方法里應盡量避免重復定義對象。與paint()方法類似在循環里也有類似的情況存在。
把所有對象的初始化放在構造函數里想必是再正當不過了,大多數人通常的做法是把當前邏輯所要用到的資源通通初始化完畢。
很大一部份的內存溢出都是發生在構造函數中。內存使用的高峰期都是在構造函數中所以避開這個高峰能有效的防止溢出。建議最好的辦法是第一次使用時初始化。如下所示
if (img==null){
//初始化
}
現在做游戲很多時候都需要地圖數組，聲音數組，還有一些其它資源這些資源很多可以放在代碼中也有的可以放在文件當中。
強烈建議將這些資源放在文件中需要時在load進來。這些資源文件如果放在代碼中則會占用不小的代碼段空間，而代碼一般是程序一運行就裝載到內存當中。
除上面列舉的方法外還有一些大家所熟知的順便一提, 比如關閉沒用的rms ，關閉沒用的網絡連接，關閉沒用的流。正確地停止線程。良好的程序架構減少代碼偶合性也是一個不錯的方法，無論在代碼調式，內存釋放都可以做到非常清析。

二. 圖片優化
j2me的內存殺手無疑非圖片莫屬,一張3k的圖片可以占用20多k的內存不信大家把load前后的內存剩余打印出來對比看看。所以防止內存溢出最直接的辦法就是從圖片入手。
1．圖片壓縮: 多數人馬上會想到這個辦法。不錯這個辦法是最有效的。在photoshop里圖片制作完成后不要選擇 "存儲為"，而是選擇 "存儲為 web 所用格式" 可以根據里面的選項進行壓縮，特別是顏色這一項越小越好不過相應的圖像會有所失真。不要認為這樣就完了。
實際上該圖片還可以再次壓縮，在網上有許多類似的工具。推薦一款可以壓縮png格式的軟件 xat.com Image Optimizer 效果不錯。經常都有 70% 的壓縮率且圖像不會失真。
假如你有多張規格一樣的圖片，那么建議你把它做成一張長條圖片。有兩個原因：
1、 這樣節省存儲空間和內存空間。大家可做個試驗將10張圖片的內容放在一張當中對比看看文件大小有沒有變化。
2 、10張圖片需要10個image 對象需要進行10次io操作浪費時間不說還浪費內存。當筆者發現這個好處時興奮地把所有圖片都存成一張，吱地一聲內存又溢出了...原因想必大家也知道!！圖片太大了不要把不同界面的圖片整合在一起否則經常會得不償失。
作圖時還有一些細節需要注意,顏色數量，分辯率，圖像模式（最好是索引顏色),畫布大小都會影響到圖片大小。

三． 工具優化
誰都知道混淆器是用來保護代碼的以加大反編譯的難度(個人認為這是在嘲笑程序員的智商）。實際上用它來優化程序也是不錯的選擇，至少有兩點好處：1、 壓縮程序大小。一個60k的程序經常可以壓掉10k左右。10k的空間對于寫低端手機的程序員簡直是雪中送碳，多少超過64k限制的游戲都受過它的恩惠；2、節省內存空間。用腳去想也想得出來代碼少了內存里的代碼段自然就短了。
根據經驗很多人都會用jb自帶的混淆器RetroGuard，實際上它效果并不怎么好。推薦使用proguard 在 http://sf.net 可以免費下載，它可以比retroguard 多壓縮3至4 k 以上而且安全性更好。

昨天在網上看到有關J2me的開發, 便想試試.於是下載了開發工具.
eclipse 3.0.1, eclipseme0.4.0安裝一切正常.

安裝後便依照網上寫了一個HelloWorld程序, 運行,怪事出來啦, 模似器一閃,馬上又自動關閉啦. 看不到效果.

今天早上反把eclipse換成3.1的, eclipseme換成1.1.0的, 再試試, 問題居然解決啦, 郁悶呀, Java這東西老是怪問題, 而且大多數都版本不兼容所引起的, 開源這東西雖然好, 可是這開源程序之間的兼容可是個大問題.

好久沒有接觸公司的程序啦, 因為一直沒出現問題所有也懶得理它,
可能是太長時間沒弄它啦, 今天上午一個小問題 居然發了我兩個小時

可以用JDK中自帶的native2ascii.exe得到.
在命令提示符下輸入: native2ascii後, 然後再輸入漢字, 就可得到所要漢的Unicode.

漢字=Unicode
零=#38646
壹=#22777
貳=#36144
叁=#21441
肆=#32902
伍=#20237
陸=#38470
柒=#26578
捌=#25420
玖=#29590
拾=#25342
佰=#20336
仟=#20191
萬=#19975
拾=#25342
佰=#20336
仟=#20191
億=#20159
整=#25972
負=#36127
分=#20998
角=#35282
元=#20803

function TForm1.ExtractString(const aString: string; const aSeparator: char; var aPos: Integer): string;
var
  I: Integer;
begin
  I := aPos;
  while (I <= Length(aString)) and (aString[I] <> aSeparator) do Inc(I);
  Result := Trim(Copy(aString, aPos, I - aPos));
  if (I <= Length(aString)) and (aString[I] = aSeparator) then Inc(I);
  aPos := I;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  lString, lSubString: string;
  lPos, j: integer;
begin
  lString := '023842394201342|343242423423|342342424|533423|2455';
  lPos := 1;
  j := 0;

  while lPos <= Length(lString) do
  begin
    lSubString := ExtractString(lString, '|', lPos);
    inc(j);
    if j = 2 then    // 第二個
      showmessage(lSubString);
  end;
end;