java設計公共組件思想

1. java培訓班一般都教什麼內容

階段一：揭開企業開發神秘面紗 (4周)
本階段主要目標是讓學員初步了解真實的企業開發流程，掌握開發JavaEE企業應用必要的基礎知識，並通過簡單B/S應用，為學員揭開企業開發的神秘面紗。
主要課程內容：
1) Web開發基礎：HTML語言、JavaScript、CSS、DOM等
2) Oracle資料庫基礎：安裝、配置Oracle資料庫，熟練掌握SQL語句
3) 操作系統：Windows /Linux的安裝、管理
4) JavaEE環境搭建：搭建JavaEE開發環境、運行環境
實踐項目：典型電子商務網站

階段二：夯實企業開發核心技術(8周)
要勝任企業開發，必須扎實掌握企業開發所需的核心技術。本階段主要目標是讓學員能夠掌握並熟練使用JavaEE企業開發所需的核心技術。
主要課程內容：
1) Java SE核心技術：Java語言核心編程技術，
2) Java EE Web開發技術：Servlet/jsP/JavaBean編程技術、MVC模式
3) Java EE流行框架技術：Struts2/Hibernate3/Spring2流行框架
4) Java EE企業開發通用組件：log4j、JFreeChart、分頁、目錄樹等
5) UML與設計模式：統一建模語言UML、經典設計模式
6) 富客戶端(RIA)開發：AJAX、Flex等
實踐項目：(一)即時通訊系統 (二)國家煙草生產銷售管理系統

階段三：模擬真實企業開發環境(4周)
掌握了企業開發核心技術後，如何正確運用到真實的企業開發流程中才是關鍵。本階段，以真實的項目、真實的流程，帶學員模擬真實的企業開發流程，為學員進行「准員工」訓練。
主要課程內容：
1) 需求分析 2) 原型設計 3) 系統設計 4) 代碼編寫 5) 測試
6) 項目提交 7) 項目評審
實戰項目：中國移動IDC運營管理系統

階段四：如何敲開企業大門（增值服務）
當具備了企業所要求的技術功底後，要敲開企業的大門，仍需要具備一些「軟技能」，本階段主要為學員提供企業前沿技術講解，職業規劃和發展指導，簡歷與面試輔導等免費服務，從各個方面保障就業。

2. Java中使用了設計模式思想的類有哪些

我就簡單的舉幾個例子吧:
1.你有沒有發現io包中有非常多的類？應該這裡面大部分都是裝飾者模式的產物。（我就不解釋裝飾者模式了）
2.不知道你有沒有使用過java swing，是不是發現很多的組件都有addListener這個方法，這就是典型的監聽者模式
3.最熟悉的一個應該是迭代模式，基本上jdk的容器都有這個模式
4.還有就是RMI，這個也應該認識吧，這個也是典型的代理模式，屬於遠程代理的
5還有一個也是在io包中的，一般你看結尾有adapter的一般都是適配器模式，
6組合模式:如果我沒記錯的話，在swing中存在樹組件吧，那個是組合模式
7工廠方法和抽象工廠模式：基本上發射中大部分都是
一下子想不起來太多==！
我覺得模式最多的是框架裡面，基本都是，最典型的就是spring了。

3. Java開發都學什麼誰在主導技術的革新

在當今互聯網信息技術大爆炸時代，人工智慧、雲計算、物聯網等正在火熱推進應用中，需要大量的軟體開發人才。Java作為一門十分熱門的軟體開發語言，是當今熱門的軟體編程語言，適合大中型企業軟體、移動應用開發。也就是學完Java軟體編程，就可以勝任很多軟體開發工作
。

只要你初中或者高中畢業，喜歡軟體編程，就可以零基礎學習JAVA軟體。因為在學校老師會手把手地叫你學習Java軟體編程的英語單詞的含義和用法。通常 Java軟體編程會學習一下內容：

如果你在學校學習基本Java基礎後，還需要熟練掌握以下技能：

1、html+div+css+javascript 網頁前端編程知識

2、MySQL數據編程知識

3、Java面向對象、集合、多線程、網路編程知識

4、JavaWeb編程jsp servelt filter listener mvc設計模式等知識

5、SpringMvc Spring Mybatis框架編程知識

6、基於MVC在線訂購系統編程實訓

以上知識和技能如果熟練掌握JavaWeb編程技能，你就能勝任大中型企業軟體、移動應用、電商訂購平台的開發。你是可以很快找到工作的！

也就是說Java工程師在基本上所有的行業的軟體開發都能勝任，通吃！

在重慶北碚龍鳳橋有家電腦培訓學校，學習Java等軟體開發技能，歡迎參觀！

4. 系統融合

系統融合，簡單的說就是把多個系統合並成一個系統。

組件化」的結果就是把系統作為一個個「組件」獨立部署並對外服務，我理解的系統「組件化」，其實是對系統 「服務化」或 「微服務化」的另一種稱呼罷了。區別在於「組件」是對外的「服務」，有些「服務」是私有的不能對外。

這里封裝了一個組件名稱為「組件1」，包含3個子服務系統，其中A服務對外開放，B、C服務是為了支持對外的A服務而存在的，但不對外開放。這里採用了「微服務」的思想把「組件1」拆分為三個子系統，有點類似java里的public方法和private方法，A系統對應public方法可以對外服務，B、C系統對應private方法只能在「組件1」內部被調用。這里所謂的服務都是通過RPC框架搭建的子系統。

新增一個「前台業務」，只要「中台系統」足夠強大，新業務可以通過調用各個公共的「組件」採用類似搭「積木」的方式，快速完成一個新業務系統開發。這應該就是阿里所謂的「小前台」、「大中台」理論基礎。
好處就是快速上線、快速試錯，「前台系統」只需要投入少量人力成本，就可以快速完成新產品的研發和上線，根據市場的反應再做調整。

前面提到的「前中台系統」建設，是站在公司組織架構層面來劃分的。個人認為 在各自所在的項目組，也可以採用這種「組件化」的思路來進行子系統拆分，在項目組內有自己的「前中台」子系統，不管這個項目是否在組織架構上屬於「前台」還是「後台」。在具體項目內部進行「前中台」子系統拆分，其實有點類似「微服務化」拆分

上圖中的「jsf服務子工程集」中的每個子工程都可以作為「組件」來看待（只是這個組件只有1個工程，但根據業務需要對每工程還可以繼續模塊化拆分），屬於「中台系統」。

上圖中的「web服務子工程集」其實就對應各種業務系統，通過調用各種基礎服務堆積而成，屬於輕量化的「前台」系統。只要「jsf服務子工程集」中的「組件化」做得足夠強大，我們就可以在項目組最大化的復用這些公共組件，更少的人力投入，快速的實現業務開發。

在這個項目「組件化」之前，是按照業務對系統進行劃分，分為pc店鋪、pc活動、m店鋪、m活動，系統劃分如下：

採用組件化的思想對系統架構進行改造，分別對前、後端都進行「組件化」提取，把公共的功能模塊提取為「組件」單獨部署。具體的業務系統調用這些公共組件達到復用的目的。改造後的系統架構如下：

todo

兩個系統融合，最大的困難就是介面不統一
比如同樣是商品介面，A、B兩個公司的介面名可能不同，商品類的定義也不同。這時為了讓外部系統調用這兩個介面無感知，就需要一個統一的介面，這就產生了適配器模式。

在「系統融合」的場景中會為同一個介面創建多個Adapter適配器（這里是兩個），分別對應多個類似業務。這里以A、B兩個電商系統融合為例，兩套系統有數十個介面我們需要在A、B兩個系統之上新建一個「適配器」系統。為了順應現在的「前中台系統建設」潮流，設計架構上對前中台進行區分，整體架構調整如下：

在A、B兩個系統沒有融合前，他們都各自對應自己的前台系統，架構說明如下：

1、A、B兩個公司合並前，都有各自對應的前台系統和中台系統。如圖中「綠色箭頭」所示。

2、現在A、B兩個公司合並，為了降低維護成本，以及增加用戶體驗，只維護一個前台系統。為了在系統融合期間，外部用戶可以正常訪問A、B前台系統，這里增加一個「新前台系統」。

3、同時為了兼容老數據，A、B兩個系統保持原樣不變，新增一個「適配器系統」，對A、B兩個系統中的公共業務介面進行適配。介面調用流程，如上圖中「紅色箭頭所示」，統一後的「前台系統」首先調用「適配器系統」，根據參數適配到A或B系統中。

4、A、B兩套系統在融合前 雖然業務類似，但也就自己的個性化業務，統一後的「前台系統」直接調用A、B系統原介面即可。如上圖中的「紫色箭頭」所示。

5、當「新前台系統」開發完成並上線後，即可關閉兩個老的前台系統。只維護一套「新前台系統」即可

通過上述系統架構，即可快速完成新系統的融合，又不影響老系統的訪問，為了防止老客戶對新系統的不適應，還可以讓「三個前台系統」並行運行一段時間。是不是有種「酷斃了」的趕腳。

這個強大的系統架構設計的核心就是設計新的「適配器系統」，這個系統里設計有多個數據介面（A、B系統公共的介面），每個介面都是採用「適配器模式」對A、B兩個系統的介面進行封裝，讓「新的前台系統」以為是一個介面。

下面就以「商品介面」為例，對「適配器模式」進行講解。

根據上述新系統架構，主要分為4個系統：「A系統」、「B系統」、新「適配器系統」、新「前台系統」。作為示例不會把4個系統都搬出來，這里使用一個java application程序進行模擬，如下：

其中兩個老系統的商品類ProctA、ProctB業務很類似：

ProctB中多一個成員變數venderId（商家Id）。現在要在新「適配器系統」中，定義新商品類Proct，需要包含兩個系統中所有業務，定義如下：

新商品對象定義完畢，現在進行介面「適配」，這里以A系統商品介面為例（B系統類似）;已有的被適配角色ProdcutManagerA（介面）、ProdcutManagerAImpl（實現類）：

新介面：新介面返回類型是新商品類Proct：

可以看到ProdcutAdapterAImpl適配器，把「A系統」商品介面 轉換為「新前台系統適配的」介面。

但在真實的系統中通過引入RPC框架和Spring IOC注入，「新前台系統」只會依賴一個「適配器」介面類：ProdcutAdapter；同時新建的「適配器系統」只依賴老A、B系統的介面類：ProdcutManagerA、ProdcutManagerB。如下圖所示：

在兩個系統融合過程中，還經常遇到另一種情況：A系統返回的商品列表是ArrayList類型，B系統返回的商品列表是數組類型。

這就是所謂的「聚合類型兼容性問題」。這時為了統一介面類型，可以在「適配器系統」把ArrayList轉換成數組，或者把數組轉換成ArrayList。但這不是最優雅的方式，我們還可以使用「迭代器模式」對兩個介面進行兼容。Java中得聚合類型：數組、List、Set、Map等。

迭代器模式提供一種順序訪問一個聚合對象中的各個元素的方法，而又不暴露其內部的表象。把遍歷聚合中各個元素的任務移交到「迭代器」上，滿足OO設計原則中的「單一責任原則」。另外具體的「迭代器」都實現自一個統一的介面（Iterator），可以兼容不同的聚合類型遍歷（這就是解決本文開頭「兼容性」問題的關鍵）。

簡單的理解，就是把聚合類型中遍歷每個成員的任務剝離出來，生成「迭代器」，這些迭代器都實現自同一個介面。類圖關系：

從類圖上看，該模式主要有4類角色：

抽象的聚合：AbsAggregate，可以是抽象類 也可以是介面。一般都會定義一個抽象方法，獲取迭代器。

具體的聚合：ConcreteAggregate，實現或繼承自AbsAggregate。一般都會實現AbsAggregate中的抽象方法，獲取具體的迭代器。

抽象的迭代器：Iterator可以是抽象類 也可以是介面。一般最少有兩個抽象方法，hasNext()和next()方法，用於遍歷聚合中的元素。

具體的迭代器：ConcreteIterator，實現或繼承自Iterator。對hasNext()和next()方法進行具體的實現。其構造過程依賴「具體的聚合」，也就是說每個「具體的聚合」，一般都會對應一個自己 「具體的迭代器」。

回到文章開頭，開始使用「迭代器模式」對A、B兩個系統融合過程中，對兩個不同的獲取商品列表介面進行融合。為了方便理解，實現過程按照「迭代器模式」的4類角色 分類進行：

Java中的迭代器：Java的API中對大部分的聚合類型都已經默認實現了自己的迭代器，統一實現自介面java.util.Iterator,相比本示例中定義的Iterator，java.util.Iterator多了一個remove方法。
Java api中幾乎已為所有的聚合類型創建了自己的迭代器，並且都實現自java.util.Iterator介面。如果要擴展自定義聚合類型的迭代器，直接實現這個介面即可，這樣做的好處是可以跟java api中的聚合類型的迭代器完全兼容。

Ref:
https://moon-walker.iteye.com/blog/2393310
https://www.jianshu.com/p/cbde4b00b7c6

5. java軟體開發的架構設計

軟體架構作為一個概念，體現在技術和業務兩個方面。
從技術角度來說：軟體架構隨著技術的革新不斷地更新其內容，軟體架構建立於當前技術和一些基本原則的基礎之上。
先說一些基本原則：
分層原則：分層是為了降低軟體深度復雜性而使用的關鍵思想，就像社會有了階級一樣，軟體有了層次結構。
模塊化原則：模塊化是化解軟體廣度復雜的必然手段，模塊化的目的就是讓軟體分工。
介面實現分離原則隨著軟體模塊化的不斷深入改進，面向介面編程而不是面向實現編程可以讓復雜度日趨增高的軟體降低模塊之間的耦合度，從而讓各模塊更輕松改進。從這個原則出發，軟體也從微觀進行了細致的規范化。
還有兩個比較小但很重要的原則：
細節隱藏原則很顯然把復雜問題簡化，把難看的細節隱去，能讓軟體結構更清晰。其實這個原則使用很普遍，java/c++語言中的封裝原則以及設計模式中的Facade(外觀)模式就很能體現這個原則的精神。
依賴倒置原則隨著軟體結構的進一步發展,層與層之間、模塊與模塊之間的依賴逐漸加深，而層、模塊的動態可插拔要求不端增大。依賴倒置原則可看視為介面實現分離原則的深化，根據此原則的精神，軟體進入了工具時代。這個原則有點類似於知名的好萊塢法則：Don't call us, we'll call you。
以上這些原則奠定了我們的軟體架構的價值指標。但軟體架構畢竟是建立在當前技術之上的。而每一代技術都有架構模式。過去的不再說了，讓我們就來看一下當前流行的技術，以及當前我們能採用的架構。
因為面向對象是當前最流行開發技術，且設計模式的大量使用使面向對象的走向成熟，而資料庫是當前最有效的存儲結構、web界面是當前最流行的用戶介面，所以當前最典型的三層次架構就架構在以上幾項技術的基礎之上，用資料庫作存儲層、用面向對象來實現業務層、用web來作為用戶介面層。我們從三層次架構談起：
因為面向對象技術和資料庫技術不適配，所以在標准三層次架構的基礎上，我們增加了數據持久層，來管理O-R雙向映射，但目前一直沒有最理想的實現技術。cmp和entity bean技術因為其實現復雜，功能前景有限，已接近被淘汰的邊緣。JDO及hibernate作為o-r映射的後期之秀，尤其是hibernate，功能相當完備。推薦作為持久層的首選
在業務層，因為當前業務日趨負載，且變動頻繁，所以我們必須有足夠敏捷的技術來保證我們的適應變化的能力，在標准j2ee系統中session bean負責業務處理，且有不錯的性能表現，但採用ejb系統對業務架構模式改變太大，且其復雜而昂貴，業務代碼移植性差。而spring 作為一個bean配置的輕量級架構，漂亮的IOC模式實現，對業務架構影響小，所以推薦作為中間層業務框架。
在用戶結構層,雖然servlet/jsp/jstl/javaBean 能夠實現MVC架構，但終究過於粗糙。struts對MVC架構的實現就比較完美，Taperstry也極好地實現MVC架構，且採用基於事件的方式，非常誘人，惜其不夠成熟，我們仍舊推薦struts作為用戶介面層基礎架構。
因為業務層是三層次架構中最有決定意義的，所以讓我們回到業務層細致地分析一下，在復雜的業務我們常常需要以下基礎服務的一種或幾種：事務一致 性服務acid(tool:jta/jts)、並發加鎖服務concurrent&&lock、池化管理服務cache、訪問控制服務(tool:jaas)、流程式控制制服務workflow、動態實現服務IOC，串列化消息服務(tool:jms)、負載平衡服務blance等。如果我們不採用重量級應用伺服器(如weblogic,websphere,jboss等)及重量級組件(EJB)，我們必須自己實現其中一些服務。雖然我們大 多情況下，不需要所有這些服務，但實現起來卻非易事。幸運的是我們有大量的開源實現代碼，但採用開源代碼卻常常是件不輕松的事。
隨著xml作為結構化信息傳輸和存儲地位日漸重要,一些xml文檔操作工具(DOM,Digester,SAX等)的使用愈發重要，而隨著 xml schema的java binding工具(jaxb,xmlbean等)工具的成熟，採用xml schema來設計xml文檔格式，然後採用java binding來生成java bean 會成為主要編程模式,而這又進一步使數據中心向xml轉移，使在中小數據量上,愈發傾向於以xquery為查詢語言的xml資料庫。現還有一個趨勢， microsoft,ibm等紛紛大量開發中間軟體如(microsoft office之infopath)，可以直接從xml schema 生成錄入頁面等非常實用的功能。還有web service 的廣泛應用，都將對軟體的架構有非常重大的影響。至於面向服務架構(SOA)前景如何，三層次架構什麼時候走入歷史，現還很難定論。
aop的發展也會對軟體架構有很深的影響，但在面向對象架構里，無論aspectJ還是jboss-aop抑是aspectWerks、 nanning都有其自身的嚴重問題：維護性很差，所以說它將很難走遠。也許作為一個很好的思想，它將在web service里大展身手。
rdf,owl作為w3c語義模型的標志性的語言，也很難想像能在當前業務架構發揮太大影響。但如果真如它所聲稱那樣，廣泛地改變著信息的結構。那麼對軟體架構也會有深遠影響。