java設計原則

Ⅰ java中，為什麼在輸入輸出中，要用捕捉異常結構語句如：

為什麼？
這個是一個java設計原則，但資料一時找不到相關資料了，你可以找一下java的異常設計。
當一個可能發生不可回逆的錯誤時就應該拋出異常，IO的輸入輸出符合這一個原則，包括網路的輸入輸出等，存在可能被中斷的情況下而發生不可回逆的數據錯誤，因此IO類會拋出異常，你必須進行對這個可能的異常進行處理，也就是須加try catch塊。

Ⅱ java.按照類的設計原則進行類的設計會帶來什麼好處

在Java語言中， abstract class 和interface 是支持抽象類定義的兩種機制。正是由於這兩種機制的存在，才賦予了Java強大的 面向對象能力。abstract class和interface之間在對於抽象類定義的支持方面具有很大的相似性，甚至可以相互替換，因此很多開發者在進 行抽象類定義時對於abstract class和interface的選擇顯得比較隨意。其實，兩者之間還是有很大的區別的，對於它們的選擇甚至反映出對 於問題領域本質的理解、對於設計意圖的理解是否正確、合理。本文將對它們之間的區別進行一番剖析，試圖給開發者提供一個在二者之間進行選擇的依據。

理解抽象類

abstract class和interface在Java語言中都是用來進行抽象類(本文 中的抽象類並非從abstract class翻譯而來，它表示的是一個抽象體，而abstract class為Java語言中用於定義抽象類的一種方法， 請讀者注意區分)定義的，那麼什麼是抽象類，使用抽象類能為我們帶來什麼好處呢?

在 面向對象的概念中，我們知道所有的對象都是通過類來描繪的，但是反過來卻不是這樣。並不是 所有的類都是用來描繪對象的，如果一個類中沒有包含足夠的信息來描繪一個具體的對象，這樣的類就是抽象類。抽象類往往用來表徵我們在對問題領域進行分析、 設計中得出的抽象概念，是對一系列看上去不同，但是本質上相同的具體概念的抽象。比如：如果我們進行一個圖形編輯軟體的開發，就會發現問題領域存在著圓、 三角形這樣一些具體概念，它們是不同的，但是它們又都屬於形狀這樣一個概念，形狀這個概念在問題領域是不存在的，它就是一個抽象概念。正是因為抽象的概念 在問題領域沒有對應的具體概念，所以用以表徵抽象概念的抽象類是不能夠實例化的。

在面向對象領域，抽象類主要用來進行類型隱藏。 我們可以構造出一個固定的一組行為的抽象描 述，但是這組行為卻能夠有任意個可能的具體實現方式。這個抽象描述就是抽象類，而這一組任意個可能的具體實現則表現為所有可能的派生類。模塊可以操作一個 抽象體。由於模塊依賴於一個固定的抽象體，因此它可以是不允許修改的;同時，通過從這個抽象體派生，也可擴展此模塊的行為功能。熟悉OCP的讀者一定知 道，為了能夠實現面向對象設計的一個最核心的原則OCP(Open-Closed Principle)，抽象類是其中的關鍵所在。

從語法定義層面看abstract class 和 interface

在語法層面，Java語言對於abstract class和interface給出了不同的定義方式，下面以定義一個名為Demo的抽象類為例來說明這種不同。

使用abstract class的方式定義Demo抽象類的方式如下：

abstract class Demo{

abstract void method1();

abstract void method2();

…

｝

使用interface的方式定義Demo抽象類的方式如下：

interface Demo{

void method1();

void method2();

…

}

Ⅲ java 流程式代碼適合什麼設計模式

總體來說設計模式分為三大類：
創建型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。
結構型模式，共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。
二、設計模式的六大原則
1、開閉原則（Open Close Principle）
開閉原則就是說對擴展開放，對修改關閉。在程序需要進行拓展的時候，不能去修改原有的代碼，實現一個熱插拔的效果。所以一句話概括就是：為了使程序的擴展性好，易於維護和升級。想要達到這樣的效果，我們需要使用介面和抽象類，後面的具體設計中我們會提到這點。
2、里氏代換原則（Liskov Substitution Principle）
里氏代換原則(Liskov Substitution Principle LSP)面向對象設計的基本原則之一。 里氏代換原則中說，任何基類可以出現的地方，子類一定可以出現。 LSP是繼承復用的基石，只有當衍生類可以替換掉基類，軟體單位的功能不受到影響時，基類才能真正被復用，而衍生類也能夠在基類的基礎上增加新的行為。里氏代換原則是對「開-閉」原則的補充。實現「開-閉」原則的關鍵步驟就是抽象化。而基類與子類的繼承關系就是抽象化的具體實現，所以里氏代換原則是對實現抽象化的具體步驟的規范。—— From Bai 網路
3、依賴倒轉原則（Dependence Inversion Principle）
這個是開閉原則的基礎，具體內容：真對介面編程，依賴於抽象而不依賴於具體。
4、介面隔離原則（Interface Segregation Principle）
這個原則的意思是：使用多個隔離的介面，比使用單個介面要好。還是一個降低類之間的耦合度的意思，從這兒我們看出，其實設計模式就是一個軟體的設計思想，從大型軟體架構出發，為了升級和維護方便。所以上文中多次出現：降低依賴，降低耦合。
5、迪米特法則（最少知道原則）（Demeter Principle）
為什麼叫最少知道原則，就是說：一個實體應當盡量少的與其他實體之間發生相互作用，使得系統功能模塊相對獨立。
6、合成復用原則（Composite Reuse Principle）
原則是盡量使用合成/聚合的方式，而不是使用繼承。

Ⅳ java中設計模式是根據什麼原則劃分的

設計模式（Design pattern）是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。

Ⅳ java中的開閉原則講的是什麼意思

開閉原則，是一種設計模式，隨著面向對象程序設計的思想，應運而生。

開，指的是可以在源代碼的基礎上進行擴展，比如繼承，介面，抽象類等。在JAVA中，之所以用繼承，是在可以直接調用類庫的前提下，對其功能進行擴展。不需要應用者去了解封裝類的內部邏輯就可以做開發。

閉，指的是原本封裝好的代碼不允許你去更改，比如JDK裡面內置的Jar包。

Ⅵ 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語義模型的標志性的語言，也很難想像能在當前業務架構發揮太大影響。但如果真如它所聲稱那樣，廣泛地改變著信息的結構。那麼對軟體架構也會有深遠影響。

Ⅶ JAVA設計模式的原則

近年來，大家都開始注意設計模式。那麼，到底我們為什麼要用設計模式呢？這么多設計模式為什麼要這么設計呢？說實話，以前我還真沒搞清楚。就是看大家一口一個"Design pattern"，心就有點發虛。於是就買了本"四人幫"的設計模式，結果看得似懂非懂:看得時候好像是懂了，過一會就忘了。可能是本人比較"愚鈍"吧:))最近，有了點感悟。"獨樂不如眾樂"，與大家分享一下，還望指教!

為什麼要提倡"Design Pattern"呢？根本原因是為了代碼復用，增加可維護性。那麼怎麼才能實現代碼復用呢？OO界有前輩的幾個原則："開－閉"原則(Open Closed Principal)、里氏代換原則、合成復用原則。設計模式就是實現了這些原則，從而達到了代碼復用、增加可維護性的目的。

一、"開－閉"原則

此原則是由"Bertrand Meyer"提出的。原文是："Software entities should be open for extension,but closed for modification"。就是說模塊應對擴展開放，而對修改關閉。模塊應盡量在不修改原(是"原"，指原來的代碼)代碼的情況下進行擴展。那麼怎麼擴展呢？我們看工廠模式"factory pattern":假設中關村有一個賣盜版盤和毛片的小子，我們給他設計一"光碟銷售管理軟體"。我們應該先設計一"光碟"介面。如圖：而盜版盤和毛片是其子類。小子通過"DiscFactory"來管理這些光碟。代碼為：

public class DiscFactory{

public static 光碟 getDisc(String name){

return (光碟)Class.forName(name).getInstance();

}}

有人要買盜版盤，怎麼實現呢？

public class 小子{

public static void main(String[] args){

光碟 d=DiscFactory.getDisc("盜版盤");

光碟.賣();

}}

如果有一天，這小子良心發現了，開始賣正版軟體。沒關系，我們只要再創建一個"光碟"的子類"正版軟體"就可以了。不需要修改原結構和代碼。怎麼樣？對擴展開發，對修改關閉。"開-閉原則"

工廠模式是對具體產品進行擴展，有的項目可能需要更多的擴展性，要對這個"工廠"也進行擴展，那就成了"抽象工廠模式"。

二、里氏代換原則

里氏代換原則是由"Barbara Liskov"提出的。如果調用的是父類的話，那麼換成子類也完全可以運行。比如：

光碟 d=new 盜版盤();

d.賣();

現在要將"盜版盤"類改為"毛片"類，沒問題，完全可以運行。Java編譯程序會檢查程序是否符合里氏代換原則。還記得java繼承的一個原則嗎？子類overload方法的訪問許可權不能小於父類對應方法的訪問許可權。比如"光碟"中的方法"賣"訪問許可權是"public"，那麼"盜版盤"和"毛片"中的"賣"方法就不能是package或private，編譯不能通過。為什麼要這樣呢？你想啊：如果"盜版盤"的"賣"方法是private。那麼下面這段代碼就不能執行了：

光碟 d=new 盜版盤();

d.賣();

可以說：里氏代換原則是繼承復用的一個基礎。

三、合成復用原則

就是說要少用繼承，多用合成關系來實現。我曾經這樣寫過程序：有幾個類要與資料庫打交道，就寫了一個資料庫操作的類，然後別的跟資料庫打交道的類都繼承這個。結果後來，我修改了資料庫操作類的一個方法，各個類都需要改動。"牽一發而動全身"!面向對象是要把波動限制在盡量小的范圍。

在Java中，應盡量針對Interface編程，而非實現類。這樣，更換子類不會影響調用它方法的代碼。要讓各個類盡可能少的跟別人聯系，"不要與陌生人說話"。這樣，城門失火，才不至於殃及池魚。擴展性和維護性才能提高

理解了這些原則，再看設計模式，只是在具體問題上怎麼實現這些原則而已。張無忌學太極拳，忘記了所有招式，打倒了"玄冪二老"，所謂"心中無招"。設計模式可謂招數，如果先學通了各種模式，又忘掉了所有模式而隨心所欲，可謂OO之最高境界。呵呵，搞笑，搞笑！

這是我的一點心得，大家可能理解得更深刻。還望指教！

Ⅷ JAVA23種設計模式

一、大約分為三類：

1、創建型模式（5種）：工廠方法模式，抽象工廠模式，單例模式，建造者模式，原型模式。

二、設計模式遵循的原則有6個：

1、開閉原則（Open Close Principle）

對擴展開放，對修改關閉。

2、里氏代換原則（Liskov Substitution Principle）

只有當衍生類可以替換掉基類，軟體單位的功能不受到影響時，基類才能真正被復用，而衍生類也能夠在基類的基礎上增加新的行為。

3、依賴倒轉原則（Dependence Inversion Principle）

這個是開閉原則的基礎，對介面編程，依賴於抽象而不依賴於具體。

4、介面隔離原則（Interface Segregation Principle）

使用多個隔離的借口來降低耦合度。

5、迪米特法則（最少知道原則）（Demeter Principle）

一個實體應當盡量少的與其他實體之間發生相互作用，使得系統功能模塊相對獨立。

6、合成復用原則（Composite Reuse Principle）

原則是盡量使用合成/聚合的方式，而不是使用繼承。繼承實際上破壞了類的封裝性，超類的方法可能會被子類修改。

Ⅸ 面試中被問到了Java中的「六原則一法則」是什麼

原則包括：
單一職責原則：一個類只做它該做的事情。(單一職責原則想表達的就是」高內聚」，寫代碼最終極的原則只有六個字」高內聚、低耦合」，就如同葵花寶典或辟邪劍譜的中心思想就八個字」欲練此功必先自宮」，所謂的高內聚就是一個代碼模塊只完成一項功能，在面向對象中，如果只讓一個類完成它該做的事，而不涉及與它無關的領域就是踐行了高內聚的原則，這個類就只有單一職責。提醒大家有一句話叫」因為專注，所以專業」，一個對象如果承擔太多的職責，那麼註定它什麼都做不好。這個世界上任何好的東西都有兩個特徵，一個是功能單一，好的相機絕對不是電視購物裡面賣的那種一個機器有一百多種功能的，它基本上只能照相;另一個是模塊化，好的自行車是組裝車，從減震叉、剎車到變速器，所有的部件都是可以拆卸和重新組裝的，好的乒乓球拍也不是成品拍，一定是底板和膠皮可以拆分和自行組裝的，一個好的軟體系統，它裡面的每個功能模塊也應該是可以輕易的拿到其他系統中使用的，這樣才能實現軟體復用的目標。)
開閉原則：軟體實體應當對擴展開放，對修改關閉。(在理想的狀態下，當我們需要為一個軟體系統增加新功能時，只需要從原來的系統派生出一些新類就可以，不需要修改原來的任何一行代碼。要做到開閉有兩個要點：①抽象是關鍵，一個系統中如果沒有抽象類或介面系統就沒有擴展點;②封裝可變性，將系統中的各種可變因素封裝到一個繼承結構中，如果多個可變因素混雜在一起，系統將變得復雜而混亂，如果不清楚如何封裝可變性，可以參考《設計模式精解》一書中對橋梁模式的講解的章節。)

依賴倒轉原則：面向介面編程。(該原則說得直白和具體一些就是聲明方法的參數類型、方法的返回類型、變數的引用類型時，盡可能使用抽象類型而不用具體類型，因為抽象類型可以被它的任何一個子類型所替代，請參考下面的里氏替換原則。)

里氏替換原則：任何時候都可以用子類型替換掉父類型。(關於里氏替換原則的描述，Barbara Liskov女士的描述比這個要復雜得多，但簡單的說就是能用父類型的地方就一定能使用子類型。里氏替換原則可以檢查繼承關系是否合理，如果一個繼承關系違背了里氏替換原則，那麼這個繼承關系一定是錯誤的，需要對代碼進行重構。例如讓貓繼承狗，或者狗繼承貓，又或者讓正方形繼承長方形都是錯誤的繼承關系，因為你很容易找到違反里氏替換原則的場景。需要注意的是：子類一定是增加父類的能力而不是減少父類的能力，因為子類比父類的能力更多，把能力多的對象當成能力少的對象來用當然沒有任何問題。
介面隔離原則：介面要小而專，絕不能大而全。(臃腫的介面是對介面的污染，既然介面表示能力，那麼一個介面只應該描述一種能力，介面也應該是高度內聚的。例如，琴棋書畫就應該分別設計為四個介面，而不應設計成一個介面中的四個方法，因為如果設計成一個介面中的四個方法，那麼這個介面很難用，畢竟琴棋書畫四樣都精通的人還是少數，而如果設計成四個介面，會幾項就實現幾個介面，這樣的話每個介面被復用的可能性是很高的。Java中的介面代表能力、代表約定、代表角色，能否正確的使用介面一定是編程水平高低的重要標識。)
合成聚合復用原則：
優先使用聚合或合成關系復用代碼。(通過繼承來復用代碼是面向對象程序設計中被濫用得最多的東西，因為所有的教科書都無一例外的對繼承進行了鼓吹從而誤導了初學者，類與類之間簡單的說有三種關系，Is-A關系、Has-A關系、Use-A關系，分別代表繼承、關聯和依賴。其中，關聯關系根據其關聯的強度又可以進一步劃分為關聯、聚合和合成，但說白了都是Has-A關系，合成聚合復用原則想表達的是優先考慮Has-A關系而不是Is-A關系復用代碼，原因嘛可以自己從網路上找到一萬個理由，浙江優就業需要說明的是，即使在Java的API中也有不少濫用繼承的例子，例如Properties類繼承了Hashtable類，Stack類繼承了Vector類，這些繼承明顯就是錯誤的，更好的做法是在Properties類中放置一個Hashtable類型的成員並且將其鍵和值都設置為字元串來存儲數據，而Stack類的設計也應該是在Stack類中放一個Vector對象來存儲數據。記住：任何時候都不要繼承工具類，工具是可以擁有並可以使用的，而不是拿來繼承的。)
法則指迪米特法則：迪米特法則又叫最少知識原則，一個對象應當對其他對象有盡可能少的了解。(迪米特法則簡單的說就是如何做到」低耦合」，門面模式和調停者模式就是對迪米特法則的踐行。對於門面模式可以舉一個簡單的例子，你去一家公司洽談業務，你不需要了解這個公司內部是如何運作的，你甚至可以對這個公司一無所知，去的時候只需要找到公司入口處的前台美女，告訴她們你要做什麼，她們會找到合適的人跟你接洽，前台的美女就是公司這個系統的門面。再復雜的系統都可以為用戶提供一個簡單的門面，Java Web開發中作為前端控制器的Servlet或Filter不就是一個門面嗎，瀏覽器對伺服器的運作方式一無所知，但是通過前端控制器就能夠根據你的請求得到相應的服務。調停者模式也可以舉一個簡單的例子來說明，例如一台計算機，CPU、內存、硬碟、顯卡、音效卡各種設備需要相互配合才能很好的工作，但是如果這些東西都直接連接到一起，計算機的布線將異常復雜，在這種情況下，主板作為一個調停者的身份出現，它將各個設備連接在一起而不需要每個設備之間直接交換數據，這樣就減小了系統的耦合度和復雜度)
這個問題在Java中屬於比較基礎的問題，但是也請題主不要灰心。面試是一個考量綜合素質的過程，即使一兩道題發揮不好也仍然擁有機會。

Ⅹ javaBean設計原則

JavaBean 是一種JAVA語言寫成的可重用組件。為寫成JavaBean，類必須是具體的和公共的，並且具有無參數的構造器。JavaBean 通過提供符合一致性設計模式的公共方法將內部域暴露成員屬性。眾所周知，屬性名稱符合這種模式，其他Java 類可以通過自身機制發現和操作這些JavaBean 屬性。