David Berlind原著‧陳奭璁譯 2003/02/06 (摘自Taiwan.CNET.com)
http://www.zdnet.com.tw/enterprise/technology/0,2000085680,20065321,00.htm
這篇文章非常好，如何解決因內部各種異質IT基礎設施與OS專用的老舊程式阻礙公司進步? 如何讓系統間相容，容易整合? 整理為下面四部份
1.每個平台商業邏輯都必需經過標準化，以便與其他平台作溝通, 例如採用Java當作商業邏輯層
2.選擇一個整合開發平台，一體適用在整個基礎設施上
3.加入一層界面來作統一的呈現，例如用Web為統一的呈現層。
4.選擇適用於各個部分的開放原始碼元件包括IDE、Web伺服器、J2EE伺服器等。
2005年12月27日
2005年12月23日
Java繼承結構中建構子的注意事項
本例中Panda及Koala新增一個物件, 其成員變數count會加一, 但是執行結果Bear的count也會計數, 為何會這樣?
原因 :
程式編譯時Java都會自動在所有類別的建構子(Constructor)的第一行加上super()來呼叫父類別的建構子
因此下面例子中不但Koala, Panda的count會計數, 連父類別Bear的count也會計數Koala為1, Panda為3, Bear為4
原因 :
程式編譯時Java都會自動在所有類別的建構子(Constructor)的第一行加上super()來呼叫父類別的建構子
因此下面例子中不但Koala, Panda的count會計數, 連父類別Bear的count也會計數Koala為1, Panda為3, Bear為4
2005年12月22日
Java多型在member variable與method的差異
一個物件的成員變數(member variable), 是存取自物件所宣告的Class
本例中物件b, 被宣告為Bear, 因此b.name的內容為Bear成員變數name的內容
但是呼叫此物件的方法(method), 則是執行自此物件實體的Class
本例中物件b,實體的Class為Koala, 因此b.name()將執行Koala的name()
2005年12月20日
SAP xCQM(xApp Cost and Quotation Management)簡介
From www.sap.com
多數製造業,Quotations(報價)是關鍵成功要素, 報價過高會失去新的生意,報價太低則影響到利潤, SAP xCQM可以控制報價產生的因素的可行性,如成本資訊, 可以管理報價並提升內外部成本的估算,可以讓報價更為準確, 透過xcqm可以整合成本估算及報價準備, 以加速議價的速度. 另外可以指定適當的資源, 用於最有希望的商機上面. 因此可以取得競爭優勢及穩定的客戶基礎. 創造企業更多的利潤.
xCQM是組合現有SAP系統功能的應用系統
Please see: SAP Cost and Quotation Management (SAP xCQM)
多數製造業,Quotations(報價)是關鍵成功要素, 報價過高會失去新的生意,報價太低則影響到利潤, SAP xCQM可以控制報價產生的因素的可行性,如成本資訊, 可以管理報價並提升內外部成本的估算,可以讓報價更為準確, 透過xcqm可以整合成本估算及報價準備, 以加速議價的速度. 另外可以指定適當的資源, 用於最有希望的商機上面. 因此可以取得競爭優勢及穩定的客戶基礎. 創造企業更多的利潤.
xCQM是組合現有SAP系統功能的應用系統
Please see: SAP Cost and Quotation Management (SAP xCQM)
2005年12月11日
[觀念筆記]多型的觀念與實用範例
多型的目的在於 "實作與介面分離" ,
一般多型是應用在繼承的關係裡面, 假設甲寫好一個 Base class 給大家拿來extends , 我們拿到這個 Base class 之後,會在新的 subclass 中去 override base class 的 method ,甲寫的 base class 基本上可以被視為是一種 interface (概念上的), 其他人寫的subclass 中的 method 則是實際 implementation 的部份 (你可以假設甲的 base class 中完全沒有任何 method 的 implementation )這樣一來, 外界只需要知道 甲的 base class 中定義的 method 有那些, 不必管是如何 implement
再舉個更實際的範例, Collection 這個概念, collection 在JDK 裡面其實是個 interface, 像是 vector ,stack 這些東西都是去 implement collection 這個interface .
當我們在寫程式的時候, 可以這樣寫 :
Vector c = new Vector();
另外可能會有一個 method (別人寫的) 它的格式是這樣的
public void test (Vector c) {
......
}
別人寫的這個 method 嘗試著要把我們宣告的 vector object 當作參數傳進去, 試著想想看, 如果當有一天我們要從 Vector 改用其他的資料結構如 stack, 會付出多大的 effort ?
除了修改我們自己的 code, 我們必須去修改所有把我們的 vector object當作參數的 method ~~~
這個時候多型就派的上用場了 :-) 如果別人程式是這樣寫的:
public void test(Collection c) {
......
}
直接把最高層的 interface / class 拿來當作參數, 那麼我們要從 vector 改成stack 只要做一件事情 :
Collection c = new Stack();
就是這麼簡單,
當別人的 method 接收到 c 這個 "reference variable", c 會去自動連結對應的subclass 及其 method (或是 implement 此 interface 的 class)
也就是說, 外界的人根本不必 care 我們實作的方式改變與否, 它們只要跟 base class (interface) 溝通即可~~
如此一來便達成 "實作與介面分離" 的目的囉 ~~
另外補充一下, 所謂的 interface 是可以拿來宣告 "reference variable" 的, 也就是像 Collection c ; 這樣做,但是後面要實際 new 一個 object instance 出來, interface 就做不到了, 它雖然也是class 的一種, 但是 interface 裡面根本沒有任何實作 ~~~
所以後面應該接 implement 此 interface 之 class 的 constructor (Vector, Stack 均 implement Collection interface)
Author : Silver
一般多型是應用在繼承的關係裡面, 假設甲寫好一個 Base class 給大家拿來extends , 我們拿到這個 Base class 之後,會在新的 subclass 中去 override base class 的 method ,甲寫的 base class 基本上可以被視為是一種 interface (概念上的), 其他人寫的subclass 中的 method 則是實際 implementation 的部份 (你可以假設甲的 base class 中完全沒有任何 method 的 implementation )這樣一來, 外界只需要知道 甲的 base class 中定義的 method 有那些, 不必管是如何 implement
再舉個更實際的範例, Collection 這個概念, collection 在JDK 裡面其實是個 interface, 像是 vector ,stack 這些東西都是去 implement collection 這個interface .
當我們在寫程式的時候, 可以這樣寫 :
Vector c = new Vector();
另外可能會有一個 method (別人寫的) 它的格式是這樣的
public void test (Vector c) {
......
}
別人寫的這個 method 嘗試著要把我們宣告的 vector object 當作參數傳進去, 試著想想看, 如果當有一天我們要從 Vector 改用其他的資料結構如 stack, 會付出多大的 effort ?
除了修改我們自己的 code, 我們必須去修改所有把我們的 vector object當作參數的 method ~~~
這個時候多型就派的上用場了 :-) 如果別人程式是這樣寫的:
public void test(Collection c) {
......
}
直接把最高層的 interface / class 拿來當作參數, 那麼我們要從 vector 改成stack 只要做一件事情 :
Collection c = new Stack();
就是這麼簡單,
當別人的 method 接收到 c 這個 "reference variable", c 會去自動連結對應的subclass 及其 method (或是 implement 此 interface 的 class)
也就是說, 外界的人根本不必 care 我們實作的方式改變與否, 它們只要跟 base class (interface) 溝通即可~~
如此一來便達成 "實作與介面分離" 的目的囉 ~~
另外補充一下, 所謂的 interface 是可以拿來宣告 "reference variable" 的, 也就是像 Collection c ; 這樣做,但是後面要實際 new 一個 object instance 出來, interface 就做不到了, 它雖然也是class 的一種, 但是 interface 裡面根本沒有任何實作 ~~~
所以後面應該接 implement 此 interface 之 class 的 constructor (Vector, Stack 均 implement Collection interface)
Author : Silver
[觀念筆記]Java 存取修飾子 protected 與 default的差別
作者 : Fred Wang 日期 :2005/12/11 修訂日期 : 2013/5/26
private methods 只能在同一個class存取
default methods(不加修飾子) 同個package內的class 都可以存取or繼承
下面範例顯示五種變數存取權，i1是private, i2是default, i3是protected, i4是public, i5是method中的local變數，同一個package中class Base中的i1無法被子class j0302中的method讀取，default, protected與public都可以
protected 具有 default 的權限, 不同之處在於, 如果"subclass"(如上例中的j0302)與主class(如上例中的Base)在不同的package中, default 就無法讓subclass存取了, protected與public才可以
假設甲寫好一個Base class, 放在 com.free.util 的package裡面,在此 class 中的變數與methods 有 default 與 protected 兩種
現在乙另一個名為com.free.app1的package中寫一個 class j0302 要繼承(extend)甲寫好的 Base class, 在此 subclass 中, 僅能去存取Base class中 protected形態的methods與變數, 對於 default形態的methods 與變數是無法使用的 !
所以結論是 : 當您撰寫一個 class, 希望有一些 methods與變數不要給所有人用(public才是給所有class都可以用), 僅給會繼承(extend) 此類別的 subclass 使用 (此 subclass 可能位於相同或不同的package中) 請將這些 methods 與變數設成 protected
private methods 只能在同一個class存取
default methods(不加修飾子) 同個package內的class 都可以存取or繼承
下面範例顯示五種變數存取權，i1是private, i2是default, i3是protected, i4是public, i5是method中的local變數，同一個package中class Base中的i1無法被子class j0302中的method讀取，default, protected與public都可以
protected 具有 default 的權限, 不同之處在於, 如果"subclass"(如上例中的j0302)與主class(如上例中的Base)在不同的package中, default 就無法讓subclass存取了, protected與public才可以
假設甲寫好一個Base class, 放在 com.free.util 的package裡面,在此 class 中的變數與methods 有 default 與 protected 兩種
現在乙另一個名為com.free.app1的package中寫一個 class j0302 要繼承(extend)甲寫好的 Base class, 在此 subclass 中, 僅能去存取Base class中 protected形態的methods與變數, 對於 default形態的methods 與變數是無法使用的 !
所以結論是 : 當您撰寫一個 class, 希望有一些 methods與變數不要給所有人用(public才是給所有class都可以用), 僅給會繼承(extend) 此類別的 subclass 使用 (此 subclass 可能位於相同或不同的package中) 請將這些 methods 與變數設成 protected
訂閱：
文章 (Atom)