繼續學習Spring,在web上面的應用,spring的關鍵,是將業務類在spring框架中注冊,也就是在xml文件中,其中包括類的屬性的初始化,這有個屬性注入的概念,常用的有構造方法注入,和set方法注入,還有一種不常用的接口注入,Class.forName();,注冊以后,在控制器中使用的時候,通過spring框架來創建對象,然后我們來使用這個對象,其中這里有個很重要的要求就是,面向接口編程,要實現一個業務類,必須先定義一個該業務類的接口,然后讓實現類實現它,這樣做的好處可以隱藏實現類的內部實現,將想讓客戶見到的方法放到接口中,這樣實現隱藏其他不想公開的方法。另外從客戶的角度來看,客戶只是得到了一個實現類的接口類型,并沒有得到具體的實現類,甚至不知道實現類的名字,面向接口編程。
另外,IoR是一種設計思想,將類的創建,管理,銷毀,還有單一模式,這一檔子事全部交給別人來負責,客戶只拿來使用創建好的對象,為客戶帶來了簡便,使更多的精力放到業務放到業務處理上,另外,也帶來了代碼的松耦合。
一天下來還是頭疼,不知怎么搞得,感冒還是沒好利索,今天抽時間將編程思想的對象初始化看完了,接下來計劃復習Struts。
昨天晚上裝jbuilder2006遇上安裝好后不能啟動的問題,從網上找的解決問題的辦法。
安裝 JBuilder 后第一次可以成功運行,可是機器重新啟動之后再次運行 JBuilder 時卻每次只是看到 Logo 閃了一下就沒有任何反應了。
這種情況主要是由于 VM 的內存分配設置出了問題。可以在 X:\JBuilder2006\bin 目錄下找到一個名為 jbuilder.config 的文件,打開該文件,其中有如下一行設置:
# Tune this VM to provide enough headroom to work on large
# applications
vmmemmin 32m
vmmemmax 75%
vmparam -XX:MaxPermSize=128m
將其改為:
# Tune this VM to provide enough headroom to work on large
# applications
vmmemmin 32m
vmmemmax 512m
vmparam -XX:MaxPermSize=128m
即可解決上述問題。
今天講spring的MVC實現,理論上跟Struts差不多,只是換湯不換藥,目前只是接觸到了Spring的控制器和模型之間是如何聯系的,Spring利用IoC實現了松耦合。這是比Struts先進的地方。
今天接觸到了Spring,我喜歡的名字,呵呵,Spring應用框架是應用于業務層的框架,要求面向接口編程,將類與類之間的關系進行解耦,Spring最基本的就是IoR(Inversion of Control)翻譯過來是控制反轉,是一種設計模式,使應用程序邏輯外在化,將創建對象,初始化,銷毀交給spring來管理,通過動態加載來使用對象。
好久沒有打代碼了,今天問起strues的東西,都有點陌生了,不行,得好好復習不行。今天一天下來頭疼,不知為什么,精力太集中了?呵呵。
今天發現有個人去工作了,哦天,呆兩天不會來再哦天。
頭疼,回家。
無意中發現baidu的blog可以從別的地方搬家,哈哈,拉攏我們的好辦法,決定試一下,哈哈轉過來了,還不錯,除了因為我原來的頁面有背景,字體設成白色的了,在這邊顯示不出來,讓我甚是不爽,改了半天,這下終于行了,還不錯。
感覺baidu的速度還是相當快的。/
類與類之間的關系對于理解面向對象具有很重要的作用,以前在面試的時候也經常被問到這個問題,在這里我就介紹一下。
類與類之間存在以下關系:
(1)泛化(Generalization)
(2)關聯(Association)
(3)依賴(Dependency)
(4)聚合(Aggregation)
UML圖與應用代碼例子:
1.泛化(Generalization)
[泛化]
表示類與類之間的繼承關系,接口與接口之間的繼承關系,或類對接口的實現關系。一般化的關系是從子類指向父類的,與繼承或實現的方法相反。
[具體表現]
父類 父類實例=new 子類()
[UML圖](圖1.1)

圖1.1 Animal類與Tiger類,Dog類的泛化關系
[代碼表現]
- class Animal{}
- class Tiger extends Animal{}
- public class Test
- {
- public void test()
- {
- Animal a=new Tiger();
- }
- }
2.依賴(Dependency)
[依賴]
對于兩個相對獨立的對象,當一個對象負責構造另一個對象的實例,或者依賴另一個對象的服務時,這兩個對象之間主要體現為依賴關系。
[具體表現]
依賴關系表現在局部變量,方法的參數,以及對靜態方法的調用
[現實例子]
比如說你要去擰螺絲,你是不是要借助(也就是依賴)螺絲刀(Screwdriver)來幫助你完成擰螺絲(screw)的工作
[UML表現](圖1.2)

圖1.2 Person類與Screwdriver類的依賴關系
[代碼表現]
- public class Person{
- /** 擰螺絲 */
- public void screw(Screwdriver screwdriver){
- screwdriver.screw();
- }
- }
3.關聯(Association)
[關聯]
對于兩個相對獨立的對象,當一個對象的實例與另一個對象的一些特定實例存在固定的對應關系時,這兩個對象之間為關聯關系。
[具體表現]
關聯關系是使用實例變量來實現
[現實例子]
比如客戶和訂單,每個訂單對應特定的客戶,每個客戶對應一些特定的訂單;再例如公司和員工,每個公司對應一些特定的員工,每個員工對應一特定的公司
[UML圖] (圖1.3)

圖1.3 公司和員工的關聯關系
[代碼表現]
- public class Company{
- private Employee employee;
- public Employee getEmployee(){
- return employee;
- }
- public void setEmployee(Employee employee){
- this.employee=employee;
- }
- //公司運作
- public void run(){
- employee.startWorking();
- }
- }
(4)聚合(Aggregation)
[聚合]
當對象A被加入到對象B中,成為對象B的組成部分時,對象B和對象A之間為聚集關系。聚合是關聯關系的一種,是較強的關聯關系,強調的是整體與部分之間的關系。
[具體表現]
與關聯關系一樣,聚合關系也是通過實例變量來實現這樣關系的。關聯關系和聚合關系來語法上是沒辦法區分的,從語義上才能更好的區分兩者的區別。
[關聯與聚合的區別]
(1)關聯關系所涉及的兩個對象是處在同一個層次上的。比如人和自行車就是一種關聯關系,而不是聚合關系,因為人不是由自行車組成的。
聚合關系涉及的兩個對象處于不平等的層次上,一個代表整體,一個代表部分。比如電腦和它的顯示器、鍵盤、主板以及內存就是聚集關系,因為主板是電腦的組成部分。
(2)對于具有聚集關系(尤其是強聚集關系)的兩個對象,整體對象會制約它的組成對象的生命周期。部分類的對象不能單獨存在,它的生命周期依賴于整體類的對象的生命周期,當整體消失,部分也就隨之消失。比如張三的電腦被偷了,那么電腦的所有組件也不存在了,除非張三事先把一些電腦的組件(比如硬盤和內存)拆了下來。
[UML圖](圖1.4)

圖1.3 電腦和組件的聚合關系
[代碼表現]
- public class Computer{
- private CPU cpu;
- public CPU getCPU(){
- return cpu;
- }
- public void setCPU(CPU cpu){
- this.cpu=cpu;
- }
- //開啟電腦
- public void start(){
- //cpu運作
- cpu.run();
- }
- }
[參考資料]
1.《Java與模式》(閻宏 編著) 第2章 統一建模語言UML簡介
突然感覺自己是個木訥的人,還矯情的寫寫心情,呵呵,女不女人。
時間過的真快,天氣已經很冷了,開始越來越擔心,這個年該怎么過,話雖說,車到山前必有路,但還是免不了不知如何是好。
想想,我想要的,其實我也不想太奢侈,自己的路真想自己走,就應該自己走,可是...
哪有那么多可是,男人一點。
我該表明我的觀點,我的立場,唉,頭暈/
跟著感覺走吧。
Oracle數據庫課結束了,老師上完課坐晚上的火成回沈陽,專業Oracle數據庫老師,當老師還是不錯的嘛,呵呵。
下周就是Spring/冬眠了呵呵,接著Struts繼續研究代碼的階段,也不能單純的研究代碼不是,MVC,設計模式,面向對象,這是最基本的,好好研究編程思想吧。
自己好好學吧,靠別人是不行的,也不要多管閑事。
數據庫,存儲過程,游標
沒什么具體寫的,心情不好,身體也不好,狗日的,回家。
今天的自講因為機子連接的問題取消了。
這周接著講Oracle,
今天脖子特別疼,還比較困,老師一講就犯困了,
晚上還好,郭斌斌講了繼承,還不錯,蠻有收獲。哎呦脖子疼,剛剛發現手機欠費了,買了張充值卡充上了,還是說我欠費不讓我打電話,真是氣死我,狗日的移動。
脖子疼好些了,嗓子又腫了,昨晚一晚上沒睡好,還挺厲害,中午買了點消炎藥,昨晚開玩笑說,以后我掙的錢還供不上吃藥的,呵呵,還活著干啥。
數據庫講了一些如何配置,然后是一些sql語句oracle獨有的,老師的水平還是厲害的,看得出來,就是有些靦腆哈哈,感到oracle還是很強大的,有很多它獨有的東西。要想學好它可是要費一段功夫的。
昨晚的講課進行的不好,感覺的在糊弄我們,也沒說什么,唉0能說什么呢,今天鄧講內部類,挺麻煩的東西。
最后一天uml,行為模式,Chain of Responsibility (COR)職責鏈模式,Command模式,Iterator迭代器模式,Mediator模式,Memento備忘錄模式,Visitor訪問者模式,Strategy策略模式,State狀態模式。
COR模式,職責鏈模式,定義一個接口,有一個處理方法,有一個該接口類型的字段,并且有一個該字段的set設置方法,不同的職責分別實現該接口,處理方法判斷是否是自己的方法,如果是,處理,如果不是,利用接口里定義的字段訪問下一個職責的處理方法,在客戶端,建立各個職責的對象,并用set方法設置下一個職責是哪一個,最后調用第一個職責的處理方法。
Command模式,國王發好施令,定義一個命令接口,用于發布命令,實現該接口,有一個士兵類屬性,構造器負責傳入士兵對象,用于讓那個士兵去執行該命令,士兵類,士兵類里面有具體執行命令的方法,國王類,有發布命令的方法,在客戶端,實例化一個士兵,實例化一個發布命令類,將士兵對象作為參數傳給命令類,實例化一個國王對象,將命令對象作為參數傳給國王,國王發號施令。
Iterator迭代器,就像集合里面有個方法可以得到Iterator對象,用于遍歷、排序。
Mediator媒體模式,由多個類需要調用,將這幾個類組合到一個類,在這個類里面有每個類類型的屬性,讓客戶端實例化這個類,不需關心其他類。
Memento模式,建立一個跟已有的類一模一樣的類,用于保存在某個時刻的值,防止后悔,呵呵!已有類里面有個memento類的對象。
Visitor訪問者模式,解決了泛型要解決的問題,利用多態,多態真是太有用了,哈哈,我覺得很多設計模式都用了多態特性。
Strategy策略模式
State狀態模式
今天下課給大家講了講第三章,比較簡單,但是不夠自信,怕自己說錯了,呵呵,還好,大家都分了一章,下星期都安排好了,安排好后幾個人又開始玩cs了,怎么能這樣呢,還不好意思說他們,唉…
設計模式,創建型模式,工廠方法,Builder模式
工廠方法就是建一個工廠類,這個工廠類負責生產對象,生產需要的對象,生成什么樣的對象由調用工廠方法的對象決定,也可以由xml文件配置,就像在struts里面配置action。隨著工廠類的增多,可以將工廠類抽象,然后由子類繼承。
Builder模式,可以單獨有一個類負責另一個類的對象的創建。我的理解,可以
Interface Car{};
class BuildCar
{
class RedCar implements Car
{}
Public Car getCar()
{
return new RedCar();
}
}
就像10-12日的那個例子,我想這就用了Builder模式。另外,Builder模式還可以有一個叫導向器的類Director,它負責怎樣創建這個對象,適用于幾個類的屬性基本相同,只有少許不同,這樣用到導向器,實現Builder類的重用。
基礎太重要了,高樓大廈的基石,好好看java編程思想。老師建議我們每個人一人一章,然后負責給每個人講解,這樣的學習效率是很高的,再有,看明白了跟講明白了是兩個層次,可是沒人相應,下課我問大家覺得老師的提議怎么樣?沒人理我,嗚嗚。大家不想學好么。
設計模式,構建型模式最后一個:Singleton單件模式
保證一個類只有一個實例存在,方法是隱藏構造方法,在類的內部構造一個靜態的實例,然后建一個靜態方法返回這個實例,其中一個知識點是,靜態變量是在main方法執行前初始化的,也就是在程序運行前初始化的。
結構性模式:適配器模式Adapter,橋接模式Bridge,組合模式Composite,裝飾模式Dectorator,外觀模式Fa ade,享元模式FlyWeight,代理模式Proxy。
Adapter模式,是多重繼承的一種替代方法,通過繼承一個類,組合一個類,來實現。
Bridge模式,將要執行的業務方法抽象出來,建立一個橋接接口,通過實現該接口用于不同的業務,然后使用該實現類。
Composite模式,多個相同的對象要調用它們的一個方法,單獨寫一個類,里面有個該對象的類的類型的集合,里面裝有許多對象,有個方法,利用循環依次調用每個對象的方法,宗旨是讓類的使用者更方便。
Dectorator模式,避免過深繼承的一種方式,目前有一個類,但業務需求改變導致這個類有少許變化,如果繼承這個類,將導致無限制繼承,辦法是建立一個這個類的兄弟,實現新的業務需求,然后調用兄弟的方法。
Fa ade模式,用于業務操作十分復雜,為了實現對復雜性的封裝,建立一個類,建立一個面向外界的接口,類的使用者只需調用該接口就搞定了,而背后復雜的邏輯不必去關心。
FlyWeight模式,跟單件模式有類似之處,都是為了減少重復對象的創建,這個模式是,建立一個緩存,將已建立的對象放入緩存,當再次需要的時候在緩存中查找是不是已經存在了該對象,如果存在,直接返回,否則創建,這樣節省了內存空間,這樣的適用于有許多的小型對象的適用。
Proxy模式,用于不同用戶有不同操作權限的類似情況,有一個類負責業務邏輯的執行并不負責用戶是否具有權限的判斷,這件任務由另一個類負責。
以上設計模式的理解,用自己的話寫了一下,希望加深理解。
明天可能要給大家講第三章,得好好準備準備,爭取完美,嘻嘻。
今天開始上uml課,老師還是很厲害的。
其中一個很容易混淆的關系就是一個依賴關系,一個關聯關系,依賴關系就是參數關系,一個類的對象作為一個參數在另一個類里被使用,而關聯關系,是一個類的對象作為另一個類的一個屬性或者集合屬性來使用。
另外,在實際設計開發中,應盡可能少的使用繼承,完全符合繼承邏輯關系的才使用繼承,以免造成代碼的混亂,關于多重繼承在java中不直接被支持,采用內部類或者關聯關系來實現。
在C++ 中有個名詞叫友元,一般情況下,子類繼承父類,子類是不能訪問父類的私有成員的,而如果一定要訪問,就在父類中將子類聲明為父類的一個朋友,這樣子類就可以使用父類的私有成員,這就是友元,在java中沒有這樣的概念。
Java基礎知識很重要,要注意復習,進一步掌握。
接著uml,接下來就應該是設計模式了,這部分都是些理論的東西,基本不用寫代碼,一些畫uml圖的含義,感覺記不住,只能到時候用到的時候,再來查查資料了,uml很重要/
感覺自己掌握的知識太欠缺了,要好好掌握基礎才行。
面向對象程序設計實際上進行的是創建新的數據類型。也可以認為,類型決定了接口,而類是該接口的一個特定實現。值得好好理解。
類描述了具有相同特性(數據元素)和行為的對象集合。