java經驗,java經驗 脫o經驗

本文目錄一覽：

• 1、java課程分享自學Java語言的經驗教訓
• 2、北大青鳥java培訓：41條面向對象經驗？
• 3、三年java經驗應該都會什麼

java課程分享自學Java語言的經驗教訓

很多年輕人躋身於Java開發行列，想要開始學習Java，覺得自學就可以，沒必要其他方式學習。但是，Java自學能學會嗎?自學Java的經驗教訓你知道多少?java課程一起來看看吧。

就好像一千個人心中有一千個哈利波特一樣，這個答案不絕對也不唯一，Java好學但自學的確阻力有些大，作為一門技術語言，它所蘊含的智慧絕對不是靠幾本入門、框架之類的書所能概括，自學Java你要做好一種英語0基礎達到4級水平的準備!

Java要學什麼?

開始就直奔主題聊語法是不對的，應該對Java基本屬性以及特點應用領域做個大概了解，可當做學習前的熱身，同樣對以後的就業也會有幫助。Java基礎語法，Java的面向對象，封裝、繼承、多態慢慢深入。

自學中會面對哪些問題?

類、集合、線程、Java網絡編程，這個學習階段經常會讓自學者感到迷茫，大腦不是空白就是混亂。一方面是：對Java了解不夠深刻，缺乏靈活應用的本領就好像我們學會了26個英文單詞，但仍舊不能寫出一串正確的句子;另一方面：缺乏獨立查找錯誤的能力。這個能力是伴隨所有程序的，無論有多少豐富的項目經驗，必須能寫代碼，還能發現bug並且能夠解決這個bug，自學者因為沒有基礎的沉澱，對Java各種編程屬性不了解，就會遇到”能正着寫，卻不能倒着推”三分時間寫代碼七分時間找bug工作效率也大打折扣。

耗盡了所有的耐力，學到這裡才是Java課程的基礎，你可能用了3個月、5個月甚至更久才勉強消化這些知識，對以後學好框架幾乎成了奢望。想要穩紮穩打，同時更快速的掌握Java技術，你需要更系統的學習更貼近企業需求的Java系統知識。

北大青鳥java培訓：41條面向對象經驗？

(1)所有數據都應該隱藏在所在的類的內部。

(2)類的使用者必須依賴類的共有接口，但類不能依賴它的使用者。

(3)盡量減少類的協議中的消息。

(4)實現所有類都理解的最基本公有接口[例如，拷貝操作(深拷貝和淺拷貝)、相等性判斷、正確輸出內容、從ASCII描述解析等等].(5)不要把實現細節(例如放置共用代碼的私有函數)放到類的公有接口中。

如果類的兩個方法有一段公共代碼，那麼就可以創建一個防止這些公共代碼的私有函數。

(6)不要以用戶無法使用或不感興趣的東西擾亂類的公有接口。

(7)類之間應該零耦合，或者只有導出耦合關係。

也即，一個類要麼同另一個類毫無關係，要麼只使用另一個類的公有接口中的操作。

(8)類應該只表示一個關鍵抽象。

包中的所有類對於同一類性質的變化應該是共同封閉的。

一個變化若對一個包影響，則將對包中的所有類產生影響，而對其他的包不造成任何影響.(9)把相關的數據和行為集中放置。

設計者應當留意那些通過get之類操作從別的對象中獲取數據的對象。

這種類型的行為暗示着這條經驗原則被違反了。

(10)把不相關的信息放在另一個類中(也即：互不溝通的行為)。

朝着穩定的方向進行依賴。

(11)確保你為之建模的抽象概念是類，而不只是對象扮演的角色。

類應當統一地共享工作。

(13)在你的系統中不要創建全能類/對象。

對名字包含Driver、Manager、System、Susystem的類要特別多加小心。

規劃一個接口而不是實現一個接口。

(14)對公共接口中定義了大量訪問方法的類多加小心。

大量訪問方法意味着相關數據和行為沒有集中存放。

(15)對包含太多互不溝通的行為的類多加小心。

這個問題的另一表現是在你的應用程序中的類的公有接口中創建了很多的get和set函數。

(16)在由同用戶界面交互的Java面向對象模型構成的應用程序中，模型不應該依賴於界面，界面則應當依賴於模型。

(17)儘可能地按照現實世界建模(我們常常為了遵守系統功能分布原則、避免全能類原則以及集中放置相關數據和行為的原則而違背這條原則).(18)從你的設計中去除不需要的類。

一般來說，我們會把這個類降級成一個屬性。

(19)去除系統外的類。

系統外的類的特點是，抽象地看它們只往系統領域發送消息但並不接受系統領域內其他類發出的消息。

(20)不要把操作變成類。

質疑任何名字是動詞或者派生自動詞的類，特別是只有一個有意義行為的類。

考慮一下那個有意義的行為是否應當遷移到已經存在或者尚未發現的某個類中。

(21)我們在創建應用程序的分析模型時常常引入代理類。

在設計階段，我們常會發現很多代理沒有用的，應當去除。

(22)盡量減少類的協作者的數量。

一個類用到的其他類的數目應當盡量少。

(23)盡量減少類和協作者之間傳遞的消息的數量。

(24)盡量減少類和協作者之間的協作量，也即：減少類和協作者之間傳遞的不同消息的數量。

(25)盡量減少類的扇出，也即：減少類定義的消息數和發送的消息數的乘積。

(26)如果類包含另一個類的對象，那麼包含類應當給被包含的對象發送消息。

也即：包含關係總是意味着使用關係。

(27)類中定義的大多數方法都應當在大多數時間裡使用大多數數據成員。

(28)類包含的對象數目不應當超過開發者短期記憶的容量。

這個數目常常是6.當類包含多於6個數據成員時，可以把邏輯相關的數據成員劃分為一組，然後用一個新的包含類去包含這一組成員。

(29)讓系統功能在窄而深的繼承體系中垂直分布。

(30)在實現語義約束時，最好根據類定義來實現。

這常常會導致類泛濫成災，在這種情況下，約束應當在類的行為中實現，通常是在構造函數中實現，但不是必須如此。

(31)在類的構造函數中實現語義約束時，把約束測試放在構造函數領域所允許的盡量深的包含層次中。

(32)Java面向對象中，約束所依賴的語義信息如果經常改變，那麼最好放在一個集中式的第3方對象中。

(33)約束所依賴的語義信息如果很少改變，那麼最好分布在約束所涉及的各個類中。

(34)類必須知道它包含什麼，但是不能知道誰包含它。

(35)共享字面範圍(也就是被同一個類所包含)的對象相互之間不應當有使用關係。

(36)繼承只應被用來為特化層次結構建模。

(37)派生類必須知道基類，基類不應該知道關於它們的派生類的任何信息。

(38)基類中的所有數據都應當是私有的，不要使用保護數據。

電腦培訓認為類的設計者永遠都不應該把類的使用者不需要的東西放在公有接口中。

(39)在理論上，繼承層次體系應當深一點，越深越好。

(40)在實踐中，繼承層次體系的深度不應當超出一個普通人的短期記憶能力。

一個廣為接受的深度值是6.(41)所有的抽象類都應當是基類。

三年java經驗應該都會什麼

沒有什麼應該要會什麼的，看個人能學到什麼程度。

如果一定要說會什麼的話，最基本的Spring、Struts2、Hibernate、Oracle、JS、Jquery等使用及原理非常熟，對於性能優化、代碼優化、服務器調優、設計模式也要有一定的認識，還要掌握一些企業常用的技術lucene、webservice、JBPM等。

對Java的認識和理解是一個長期的過程，但掌握了這些對java的最常見的應用也算學習了個大概，進入大多數公司都能遊刃有餘。

後面多考慮架構設計及底層的一些東西，目前大數據很火，可以關注下MapReduce、Hadoop等技術。