JAVA設計模式的原則

近年來，大家都開始注意設計模式。那么，到底我們?yōu)槭裁匆迷O計模式呢？這么多設計模式為什么要這么設計呢？說實話，以前我還真沒搞清楚。就是看大家一口一個"Design pattern"，心就有點發(fā)虛。于是就買了本"四人幫"的設計模式，結(jié)果看得似懂非懂:看得時候好像是懂了，過一會就忘了?？赡苁潜救吮容^"愚鈍"吧:))最近，有了點感悟。"獨樂不如眾樂"，與大家分享一下，還望指教!

成都創(chuàng)新互聯(lián)公司長期為上千家客戶提供的網(wǎng)站建設服務，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為成安企業(yè)提供專業(yè)的成都做網(wǎng)站、成都網(wǎng)站建設、成都外貿(mào)網(wǎng)站建設，成安網(wǎng)站改版等技術(shù)服務。擁有10多年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

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

一、"開－閉"原則

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

而盜版盤和毛片是其子類。小子通過"DiscFactory"來管理這些光盤。代碼為：

public class DiscFactory{

public static 光盤 getDisc(String name){

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

}}

有人要買盜版盤，怎么實現(xiàn)呢？

public class 小子{

public static void main(String[] args){

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

光盤.賣();

}}

如果有一天，這小子良心發(fā)現(xiàn)了，開始賣正版軟件。沒關(guān)系，我們只要再創(chuàng)建一個"光盤"的子類"正版軟件"就可以了。不需要修改原結(jié)構(gòu)和代碼。怎么樣？對擴展開發(fā)，對修改關(guān)閉。"開-閉原則"

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

二、里氏代換原則

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

光盤 d=new 盜版盤();

d.賣();

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

光盤 d=new 盜版盤();

d.賣();

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

三、合成復用原則

就是說要少用繼承，多用合成關(guān)系來實現(xiàn)。我曾經(jīng)這樣寫過程序：有幾個類要與數(shù)據(jù)庫打交道，就寫了一個數(shù)據(jù)庫操作的類，然后別的跟數(shù)據(jù)庫打交道的類都繼承這個。結(jié)果后來，我修改了數(shù)據(jù)庫操作類的一個方法，各個類都需要改動。"牽一發(fā)而動全身"!面向?qū)ο笫且巡▌酉拗圃诒M量小的范圍。

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

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

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

用記事本寫java代碼怎么運行？

用記事本寫完代碼后運行方法如下：

1、用瀏覽器打開用記事本編寫的代碼

新建“文本文檔”后，鼠標右鍵點擊該文本文檔，在菜單欄的“打開方式”選擇“用記事本打開”，也可以設置默認打開方式為“記事本”；用記事本打開文本文檔后，直接在該文檔內(nèi)根據(jù)自己的需要輸入想要編輯的網(wǎng)頁代碼。

2、記事本寫java代碼怎么運行

首先，需要安裝jdk并配置環(huán)境變量。然后，在命令行中，用javac命令編譯用記事本編寫的代碼。下一步，在命令行中，用java命令執(zhí)行編譯后的結(jié)果。

代碼是什么

代碼是程序員用開發(fā)工具所支持的語言寫出來的源文件，是一組由字符、符號或信號碼元以離散形式表示信息的明確的規(guī)則體系。代碼設計的原則包括唯一確定性、標準化和通用性、可擴充性與穩(wěn)定性、便于識別與記憶、力求短小與格式統(tǒng)一以及容易修改等。

計算機源代碼最終目的是將人類可讀文本翻譯成為計算機可執(zhí)行的二進制指令，這種過程叫編譯，它由通過編譯器完成。源代碼就是用匯編語言和高級語言寫出來的地代碼。目標代碼是指源代碼經(jīng)過編譯程序產(chǎn)生的能被 cpu直接識別二進制代碼。

可執(zhí)行代碼就是將目標代碼連接后形成的可執(zhí)行文件,當然也是二進制的。

北大青鳥java培訓：頁面設計的設計原則有哪些？

在公司進行APP制作的過程中，由于需要面對的用戶多種多樣，需要向用戶展示的頁面也應該是不同風格的，這樣才能滿足不同人的需求，并且這也是大數(shù)據(jù)分析后進行自動排列組合所推出的頁面，那么在進行APP制作過程中，如何如何掌握這種技巧呢？下面福建java課程為大家介紹頁面設計的設計原理。

1、通過運營方KPI、內(nèi)容和優(yōu)先級決定排版如果您希望能夠有很多用戶點擊頁面，那么內(nèi)容必須滿足用戶的需求。

如今，APP經(jīng)常使用各種維度，例如優(yōu)惠營銷活動，排名和朋友關(guān)系鏈來協(xié)助決策，以實現(xiàn)更高的轉(zhuǎn)換率。

但是在使用過程中APP的主頁才是每個運營商競爭資源的戰(zhàn)場。

電子商務業(yè)務每天都需要不同的曝光和商品類別，因此我們經(jīng)常會看到一排兩列，三列，有時甚至四列設置不同的分類。

2、采用不同的排布方法，讓頁面更加豐富在進行頁面布局的過程中，可以愛同一個頁面中采用不同的布局方法，這樣能夠讓用戶在豐富的內(nèi)容中進行了解，并且還能在頁面停留很長的時間。

福建電腦培訓發(fā)現(xiàn)現(xiàn)在很多購物網(wǎng)站都是采用這種方法，在頁面主頁中布局營銷活動入口和各種品牌專題版塊。

3、讓用戶選擇到自己喜歡的，提高轉(zhuǎn)化在非常多的內(nèi)容中，用戶需要在多個分類中找到自己喜歡的種類，所以在進行設計的過程中，應該避免單單顯示簡單的標題和圖片，這樣用戶無法在瀏覽的過程中選擇自己喜歡的。

如果想要得到很好的轉(zhuǎn)化率，福建北大青鳥建議最好在設計內(nèi)容的時候添加一些內(nèi)容作為輔助信息，這樣能夠得到更好的效果。

4、對圖片內(nèi)容進行區(qū)分在進行圖片內(nèi)容設置的過程中，如果圖片能夠區(qū)分內(nèi)容，那么在提高用戶的瀏覽效率有很大的幫助，并且能夠?qū)?nèi)容進行強化。

在圖片質(zhì)量不高的情況下，可以采用弱化圖片的方法，內(nèi)容為主，圖片為輔。

在學習電腦的過程中，很多知識都是相互貫通的，需要掌握更多的知識，去參考一些好的設計，成功的經(jīng)驗是值得很多人進行學習的。

在進行電腦培訓的過程中，學習更多有用的知識，并且多多和其他人進行溝通，對于掌握更多知識有很大的幫助。

java六大設計原則？

1、單一職責原則

不要存在多于一個導致類變更的原因，也就是說每個類應該實現(xiàn)單一的職責，如若不然，就應該把類拆分。

2、里氏替換原則(Liskov Substitution Principle)

里氏代換原則(Liskov Substitution Principle LSP)面向?qū)ο笤O計的基本原則之一。

里氏代換原則中說，任何基類可以出現(xiàn)的地方，子類一定可以出現(xiàn)。

LSP是繼承復用的基石，只有當衍生類可以替換掉基類，軟件單位的功能不受到影響時，基類才能真正被復用，而衍生類也能夠在基類的基礎(chǔ)上增加新的行為。里氏代換原則是對“開-閉”原則的補充。實現(xiàn)“開-閉”原則的關(guān)鍵步驟就是抽象化。而基類與子類的繼承關(guān)系就是抽象化的具體實現(xiàn)，所以里氏代換原則是對實現(xiàn)抽象化的具體步驟的規(guī)范?！?/p>

From Baidu 百科

歷史替換原則中，子類對父類的方法盡量不要重寫和重載。因為父類代表了定義好的結(jié)構(gòu)，通過這個規(guī)范的接口與外界交互，子類不應該隨便破壞它。

3、依賴倒轉(zhuǎn)原則(Dependence Inversion Principle)

這個是開閉原則的基礎(chǔ)，具體內(nèi)容：面向接口編程，依賴于抽象而不依賴于具體。寫代碼時用到具體類時，不與具體類交互，而與具體類的上層接口交互。

4、接口隔離原則(Interface Segregation Principle)

這個原則的意思是：每個接口中不存在子類用不到卻必須實現(xiàn)的方法，如果不然，就要將接口拆分。使用多個隔離的接口，比使用單個接口(多個接口方法集合到一個的接口)要好。

5、迪米特法則(最少知道原則)(Demeter Principle)

就是說：一個類對自己依賴的類知道的越少越好。也就是說無論被依賴的類多么復雜，都應該將邏輯封裝在方法的內(nèi)部，通過public方法提供給外部。這樣當被依賴的類變化時，才能最小的影響該類。

最少知道原則的另一個表達方式是：只與直接的朋友通信。類之間只要有耦合關(guān)系，就叫朋友關(guān)系。耦合分為依賴、關(guān)聯(lián)、聚合、組合等。我們稱出現(xiàn)為成員變量、方法參數(shù)、方法返回值中的類為直接朋友。局部變量、臨時變量則不是直接的朋友。我們要求陌生的類不要作為局部變量出現(xiàn)在類中。

6、合成復用原則(Composite Reuse Principle)

原則是盡量首先使用合成/聚合的方式，而不是使用繼承。

java程序設計有哪些設計原則

內(nèi)聚性

類應該描述一個單一的實體，而所有的類操作應該在邏輯上相互配合，支持一個一致的目的。例如：可以設計一個類用于學生，但不應該將學生與教職工組合在一個類中，因為學生和教職工是不同的實體。

如果一個實體擔負太多的職責，就應該按各自的職責分成幾個類。例如：String類、StringBuffer類和 StringBuilder類用于處理字符串，但是他們的職責不同。String類處理不變的字符串，StringBuilder類創(chuàng)建可變字符串， StringBuffer()

與 StringBuffer() 類還包含更新字符串的同步方法。

一致性

遵循標準java程序設計風格和命名習慣。為類、數(shù)據(jù)域和方法選取具有信息的名字。通常的風格是將數(shù)據(jù)聲明置于構(gòu)造方法之前，并且將構(gòu)造方法置于方法之前。

選擇名字要保持一致。給類似的操作選擇不同的名字并非良好的實踐。例如：Length() 方法返回String、StringBuilder 和 StringBuffer 的大小。如果在這些類中給這個方法用不同的名字就不一致了。

一般來說，應該具有一致性地提供一個公共無參的構(gòu)造函數(shù)，用于構(gòu)建默認實例。如果一個類不支持無參的構(gòu)造函數(shù)，要用文檔寫出原因。如果沒有顯示定義構(gòu)造方法，即假定有一個空方法體的公共默認無參構(gòu)造方法。

如果不想讓用戶創(chuàng)建類的對象，可以在類中聲明一個私有的構(gòu)造方法，Math類就是如此。

封裝性

一個類應該使用private修飾符隱藏其數(shù)據(jù)，以免用戶直接訪問它。這使得類更易于維護。只在希望數(shù)據(jù)域可讀的情況下，才提供get方法；也只在希望數(shù)據(jù)域可更新的情況下，才提供set方法。例如：Rational類為numerator和denominator提供了get方法，但是沒有提供set方法，因為Rational對象是不可改變的。

清晰性

為使設計清晰，內(nèi)聚性、一致性和封裝性都是很好的設計原則。除此之外，類應該有一個很清晰的合約，從而易于解釋和理解。

用戶可以以各種不同的組合、順序，以及在各種環(huán)境中結(jié)合使用多個類。因此，在設計一個類時，這個類不應該限制用戶如何以及何時使用該類；以一種方式設計屬性，以允許用戶按值的任何順序和任何組合來設置；設計方法應該使得實現(xiàn)的功能與他們出現(xiàn)的順序無關(guān)。例如：Loan類包含屬性loanAmount、numberOfYears和annualIntereRate，這些屬性的值，可以按任何順序來設置。

方法應在不生產(chǎn)混淆的情況下進行直觀定義。例如：String類中的substring（int beginIndex， int endIndex）方法就有一點混亂。這個方法返回從beginIndex到endIndex-1而不是endIndex的子串。該方法應該返回從beginIndex到endIndex的子字符串，從而更加直觀。

不應該聲明一個來自其他數(shù)據(jù)域的數(shù)據(jù)域。例如，下面的Person類有兩個數(shù)據(jù)域：birthDate和age。由于age可以從birthDate導出，所以age不應該聲明為數(shù)據(jù)域。

JAVA面向?qū)ο笤O計有哪些原則

甚至還有經(jīng)驗豐富的Java程序員沒有聽說過OOPS和SOLID設計原則，他們根本不知道設計原則的好處，也不知道如何依照這些原則來進行編程。 眾所周知，Java編程最基本的原則就是要追求高內(nèi)聚和低耦合的解決方案和代碼模塊設計。查看Apache和Sun的開放源代碼能幫助你發(fā)現(xiàn)其他Java設計原則在這些代碼中的實際運用。Java DevelopmentKit則遵循以下模式：BorderFactory類中的工廠模式、Runtime類中的單件模式。 原則1:DRY（Don'trepeatyourself） 即不要寫重復的代碼，而是用"abstraction"類來抽象公有的東西。如果你需要多次用到一個硬編碼值，那么可以設為公共常量；如果你要在兩個以上的地方使用一個代碼塊，那么可以將它設為一個獨立的方法。SOLID設計原則的優(yōu)點是易于維護，但要注意，不要濫用，duplicate不是針對代碼，而是針對功能。這意味著，即使用公共代碼來驗證OrderID和SSN,二者也不會是相同的。使用公共代碼來實現(xiàn)兩個不同的功能，其實就是近似地把這兩個功能永遠捆綁到了一起，如果OrderID改變了其格式，SSN驗證代碼也會中斷。因此要慎用這種組合，不要隨意捆綁類似但不相關(guān)的功能。 原則2:封裝變化 在軟件領(lǐng)域中唯一不變的就是"Change",因此封裝你認為或猜測未來將發(fā)生變化的代碼。OOPS設計模式的優(yōu)點在于易于測試和維護封裝的代碼。如果你使用Java編碼，可以默認私有化變量和方法，并逐步增加訪問權(quán)限，比如從private到protected和notpublic.有幾種Java設計模式也使用封裝，比如Factory設計模式是封裝"對象創(chuàng)建",其靈活性使得之后引進新代碼不會對現(xiàn)有的代碼造成影響。 原則3:開閉原則 即對擴展開放，對修改關(guān)閉。這是另一種非常棒的設計原則，可以防止其他人更改已經(jīng)測試好的代碼。理論上，可以在不修改原有的模塊的基礎(chǔ)上，擴展功能。這也是開閉原則的宗旨。 原則4:單一職責原則 類被修改的幾率很大，因此應該專注于單一的功能。如果你把多個功能放在同一個類中，功能之間就形成了關(guān)聯(lián)，改變其中一個功能，有可能中止另一個功能，這時就需要新一輪的測試來避免可能出現(xiàn)的問題。 原則5:依賴注入或倒置原則 這個設計原則的亮點在于任何被DI框架注入的類很容易用mock對象進行測試和維護，因為對象創(chuàng)建代碼集中在框架中，客戶端代碼也不混亂。有很多方式可以實現(xiàn)依賴倒置，比如像AspectJ等的AOP（AspectOrientedprogramming）框架使用的字節(jié)碼技術(shù)，或Spring框架使用的代理等。 原則6:優(yōu)先利用組合而非繼承 如果可能的話，優(yōu)先利用組合而不是繼承。一些人可能會質(zhì)疑，但我發(fā)現(xiàn)，組合比繼承靈活得多。組合允許在運行期間通過設置類的屬性來改變類的行為，也可以通過使用接口來組合一個類，它提供了更高的靈活性，并可以隨時實現(xiàn)。《EffectiveJava》也推薦此原則。 原則7:里氏代換原則（LSP） 根據(jù)該原則，子類必須能夠替換掉它們的基類，也就是說使用基類的方法或函數(shù)能夠順利地引用子類對象。LSP原則與單一職責原則和接口分離原則密切相關(guān)，如果一個類比子類具備更多功能，很有可能某些功能會失效，這就違反了LSP原則。為了遵循該設計原則，派生類或子類必須增強功能。 原則8:接口分離原則 采用多個與特定客戶類有關(guān)的接口比采用一個通用的涵蓋多個業(yè)務方法的接口要好。設計接口很棘手，因為一旦釋放接口，你就無法在不中斷執(zhí)行的情況下改變它。在Java中，該原則的另一個優(yōu)勢在于，在任何類使用接口之前，接口不利于實現(xiàn)所有的方法，所以單一的功能意味著更少的實現(xiàn)方法。 原則9:針對接口編程，而不是針對實現(xiàn)編程 該原則可以使代碼更加靈活，以便可以在任何接口實現(xiàn)中使用。因此，在Java中最好使用變量接口類型、方法返回類型、方法參數(shù)類型等?！禘ffectiveJava》和《headfirstdesignpattern》書中也有提到。 原則10:委托原則 該原則最典型的例子是Java中的equals（）和hashCode（）方法。為了平等地比較兩個對象，我們用類本身而不是客戶端類來做比較。這個設計原則的好處是沒有重復的代碼，而且很容易對其進行修改。 總之，希望這些面向?qū)ο蟮脑O計原則能幫助你寫出更靈活更好的代碼。理論是第一步，更重要的是需要開發(fā)者在實踐中去運用和體會。

文章標題：java代碼的設計原則 java設計六大原則
本文鏈接：http://sd-ha.com/article28/doochcp.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供、網(wǎng)站維護、軟件開發(fā)、自適應網(wǎng)站、動態(tài)網(wǎng)站、響應式網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)