從之前的Camel Case介紹可以得知,Pascal Case就是Upper Camel Case..
從wiki摘出來的說法是:
Upper Camel Case
每一個單字的首字母都採用大寫字母,例如:FirstName、LastName、CamelCase,也被稱為 Pascal 命名法
他不是很難,因為他跟Lower Camel Case的差異僅是Upper Camel Case的開頭第一個單字為大寫而已..!!
Showing posts with label Programming. Show all posts
Showing posts with label Programming. Show all posts
4/14/2009
4/13/2009
第一命名規則:Camel Case
中文就是駱駝命名法啦...!!
根據微軟的部分說法是這樣的:
識別項的第一個字母是小寫的,而每個隨後串聯文字的第一個字母是大寫的。例如:
backColor
根據Wiki的說法是:
Camel Case的詞語來自Perl語言普遍使用的大小寫混合格式...
而 Larry Wall 等人所著的暢銷書《Programming Perl》(O'Reilly 出版)的封面圖片正是一匹駱駝。」
Camel Case的限制條件,不得使用下列表式:
Lower Camel Case
第一個單字以小寫字母開始;第二個單字的首字母大寫,例如:firstName、lastName
Upper Camel Case
每一個單字的首字母都採用大寫字母,例如:FirstName、LastName、CamelCase,也被稱為 Pascal 命名法
我個人對命名的看法:
Low Camel Case
==一個字以內:==
test、color、execute、observer、singleton、factory、measurements、time、connection、stop、start、run
==兩個字情況:==
getName、setProperty、executeReader、backColor、startRunning、nationalLanguage、dataBase、threadConnection、windowFrame、actionListener、windowAdapter
==三個字情況:==
getId、getSn、setNo、lastIndexOf、trimToSize、createSystemObject、removeArrayList
==四個字以上:==
全寫出來或著
setHRDepartment、addNewWorkProject、newProcessId、destroySid、rebuildNewThread
根據微軟的部分說法是這樣的:
識別項的第一個字母是小寫的,而每個隨後串聯文字的第一個字母是大寫的。例如:
backColor
根據Wiki的說法是:
Camel Case的詞語來自Perl語言普遍使用的大小寫混合格式...
而 Larry Wall 等人所著的暢銷書《Programming Perl》(O'Reilly 出版)的封面圖片正是一匹駱駝。」
Camel Case的限制條件,不得使用下列表式:
- 單字之間不得空格,ex:back Color
- 不可使用底線區隔,ex:back_Color
- 不能使用連接符號連接單字之間,ex: back-Color
Lower Camel Case
第一個單字以小寫字母開始;第二個單字的首字母大寫,例如:firstName、lastName
Upper Camel Case
每一個單字的首字母都採用大寫字母,例如:FirstName、LastName、CamelCase,也被稱為 Pascal 命名法
我個人對命名的看法:
- 盡量不要使用縮寫,最好能在兩個單字內搞定
- 非得需要縮寫的話,請表達語意清楚,或著附加註解..!
Low Camel Case
==一個字以內:==
test、color、execute、observer、singleton、factory、measurements、time、connection、stop、start、run
==兩個字情況:==
getName、setProperty、executeReader、backColor、startRunning、nationalLanguage、dataBase、threadConnection、windowFrame、actionListener、windowAdapter
==三個字情況:==
getId、getSn、setNo、lastIndexOf、trimToSize、createSystemObject、removeArrayList
==四個字以上:==
全寫出來或著
setHRDepartment、addNewWorkProject、newProcessId、destroySid、rebuildNewThread
4/10/2009
Java中的Deadlock情況!!
要知道deadlock的前提:
Thread A占用Resource B
Thread B占用Resource A
發生情況:
Thread A將Resource B鎖定(lock)住
;同時,
Thread B將Resource A鎖定(lock)住
Thread B要取用Resource B,結果Thead A仍未處理完,要等待!
Thread A要取用Resource A,結果Thread B仍未處理完,要等待!
最終,雙方同時等待造成Deadlock!
模擬Deadlock:
1.雙方同時sleep以致不會把lock object交還..
2.Thread A的sleep時間比Thread B長
(這樣做Thread B,會以為Thread A還在處理..!因為lock object沒交還..)
3.使用synchronized關鍵字來創造critical section..
代碼如下:
public class Main{
public static void main(string args[]){
Thread threadA=new Thread(new ThreadA());
Thread threadB=new Thread(new ThreadB());
threadA.start();
threadB.start();
}//end main
}//end Main
class ThreadA implements Runnable{
ResourceA resA=ResourceA.getInstance();
ResourceB resB=ResourceB.getInstance();
public void run(){
synchronized(resB){
System.out.println("ResourceB for ThreadA is starting!");
Thread.sleep(150);
synchronized(resA){
System.out.println("ResourceA for ThreadA is starting!");
}//end synchronized
}//end synchronized
}//end run
}//end ThreadA
class ThreadB implements Runnable{
ResourceA resA=ResourceA.getInstance();
ResourceB resB=ResourceB.getInstance();
public void run(){
synchronized(resA){
System.out.println("ResourceA for ThreadA is starting!");
Thread.sleep(50);
synchronized(resB){
System.out.println("ResourceB for ThreadA is starting!");
}//end synchronized
}//end synchronized
}//end run
}//end ThreadB
//------------------------------------------------------------------
//class Resource使用Singlaton Pattern來創造獨一無二的Resource
class ResourceA{
public volatile static ResourceA uniqueInstance;//控制統一鎖
private ResourceA(){
}//end constructor
public static ResourceA getInstance(){
if(uniqueInstance==null){
synchronized(your_class_for_ResourceA_name.class){
if(uniqueInstance==null)
uniqueInstance=new ResourceA();
}//end synchronized
}//end if
return uniqueInstance;
}//end getInstance
}//end ResourceA
class ResourceB{
public volatile static ResourceB uniqueInstance;//控制統一鎖
private ResourceB(){
}//end constructor
public static ResourceB getInstance(){
if(uniqueInstance==null){
synchronized(your_class_for_ResourceB_name.class){
if(uniqueInstance==null)
uniqueInstance=new ResourceB();
}//end synchronized
}//end if
return uniqueInstance;
}//end getInstance
}//end ResourceB
//------------------------------------------------------------------
Thread A占用Resource B
Thread B占用Resource A
發生情況:
Thread A將Resource B鎖定(lock)住
;同時,
Thread B將Resource A鎖定(lock)住
Thread B要取用Resource B,結果Thead A仍未處理完,要等待!
Thread A要取用Resource A,結果Thread B仍未處理完,要等待!
最終,雙方同時等待造成Deadlock!
模擬Deadlock:
1.雙方同時sleep以致不會把lock object交還..
2.Thread A的sleep時間比Thread B長
(這樣做Thread B,會以為Thread A還在處理..!因為lock object沒交還..)
3.使用synchronized關鍵字來創造critical section..
代碼如下:
public class Main{
public static void main(string args[]){
Thread threadA=new Thread(new ThreadA());
Thread threadB=new Thread(new ThreadB());
threadA.start();
threadB.start();
}//end main
}//end Main
class ThreadA implements Runnable{
ResourceA resA=ResourceA.getInstance();
ResourceB resB=ResourceB.getInstance();
public void run(){
synchronized(resB){
System.out.println("ResourceB for ThreadA is starting!");
Thread.sleep(150);
synchronized(resA){
System.out.println("ResourceA for ThreadA is starting!");
}//end synchronized
}//end synchronized
}//end run
}//end ThreadA
class ThreadB implements Runnable{
ResourceA resA=ResourceA.getInstance();
ResourceB resB=ResourceB.getInstance();
public void run(){
synchronized(resA){
System.out.println("ResourceA for ThreadA is starting!");
Thread.sleep(50);
synchronized(resB){
System.out.println("ResourceB for ThreadA is starting!");
}//end synchronized
}//end synchronized
}//end run
}//end ThreadB
//------------------------------------------------------------------
//class Resource使用Singlaton Pattern來創造獨一無二的Resource
class ResourceA{
public volatile static ResourceA uniqueInstance;//控制統一鎖
private ResourceA(){
}//end constructor
public static ResourceA getInstance(){
if(uniqueInstance==null){
synchronized(your_class_for_ResourceA_name.class){
if(uniqueInstance==null)
uniqueInstance=new ResourceA();
}//end synchronized
}//end if
return uniqueInstance;
}//end getInstance
}//end ResourceA
class ResourceB{
public volatile static ResourceB uniqueInstance;//控制統一鎖
private ResourceB(){
}//end constructor
public static ResourceB getInstance(){
if(uniqueInstance==null){
synchronized(your_class_for_ResourceB_name.class){
if(uniqueInstance==null)
uniqueInstance=new ResourceB();
}//end synchronized
}//end if
return uniqueInstance;
}//end getInstance
}//end ResourceB
//------------------------------------------------------------------
12/29/2008
[閒閒沒事幹0002]繼承的汎生問題
從之前的繼承範例來看..
可以看出繼承雖然可以帶來reuse的特性..
但他同樣發生了一些不合理的情況..
在這個情況下..
第一個解決要訣:要將容易變動的地方抽離出來..
從該範例來看,目前變動區域為:
public void getName(String name){
System.out.println(name);
}
如果說能將其讓getName()獨立出來的話..
就可以避免Info類別再次被修改..
也變的更有彈性..
可以看出繼承雖然可以帶來reuse的特性..
但他同樣發生了一些不合理的情況..
在這個情況下..
第一個解決要訣:要將容易變動的地方抽離出來..
從該範例來看,目前變動區域為:
public void getName(String name){
System.out.println(name);
}
如果說能將其讓getName()獨立出來的話..
就可以避免Info類別再次被修改..
也變的更有彈性..
12/28/2008
[閒閒沒事幹0001]OOP的繼承..!
這是一個基礎的教學..
一般OOP的繼承可以達到重複性利用的特性..
以一個範例來看:
public class Info{
public void getName(String name){
System.out.println(name);
}
public void getInfo(){
System.out.println("This is a information!");
}
}
class Main extends Info{
public static void main(String args[]){
Main main=new Main();
main.getInfo();
main.getName("Main");
}
}
以一個上述範例來看..
這樣作便可達到重複利用的特性...
不過繼承必須要適時的情況下用...
上述範例並不是一個很好的應用..
因為他可能汎生的問題如下
public class PartInfo extends Info{
}
對PartInfo而言..
他只是想要取得getInfo()..
很可惜的..
getName()的方法對PartInfo而言也必須強迫繼承..
如果說從Info再另行修改以可能會造成牽一髮動全身的嚴重後果..
因此對整個軟體設計而言..
這是不得不去注意的...
Subscribe to:
Posts (Atom)