本文目錄一覽
- 1，接口隔離原則適用于哪個(gè)設(shè)計(jì)模式
- 2，java語言支持oop中的oop是什么
- 3，面向?qū)ο蟮奈宕笤瓌t
- 4，面向?qū)ο笪屙?xiàng)基本原則
- 5，面向?qū)ο笤O(shè)計(jì)原則開放封閉原則
- 1，接口隔離原則適用于哪個(gè)設(shè)計(jì)模式
接口隔離原則表明客戶端不應(yīng)該被強(qiáng)迫實(shí)現(xiàn)一些他們不會(huì)使用的接口，應(yīng)該把胖接口中的方法分組，然后用多個(gè)接口代替它，每個(gè)接口服務(wù)于一個(gè)子模塊。 接口隔離原則 不應(yīng)該強(qiáng)迫客戶端依賴于他們不會(huì)使用的接口。 實(shí)例 下面是一個(gè)違反了接口隔離原則的例子。我們使用Manager類代表一個(gè)管理工人的管理者。有兩種類型的工人：普通的和高效的，這兩種工人都需要吃午飯?，F(xiàn)在來了一批機(jī)器人，它們同樣為公司工作，但是他們不需要吃午飯。一方面Robot類需要實(shí)現(xiàn)IWoker接口，因?yàn)樗麄円ぷ鳎硪环矫?，它們又不需要?shí)現(xiàn)IWorker接口，因?yàn)樗鼈儾恍枰燥??！ ≡谶@種情況下IWorker就被認(rèn)為是一個(gè)被污染了的接口?！ ∪绻覀儽３脂F(xiàn)在的設(shè)計(jì)，那么Robot類將被迫實(shí)現(xiàn)eat（）方法，我們可以寫一個(gè)啞類它什么也不做（比如說它只用一秒鐘的時(shí)間吃午飯），但是這會(huì)對(duì)程序造成不可預(yù)料的結(jié)果（例如管理者看到的報(bào)表中顯示被帶走的午餐多于實(shí)際的人數(shù)）?！ 「鶕?jù)接口隔離原則，一個(gè)靈活的設(shè)計(jì)不應(yīng)該包含被污染的接口。對(duì)于我們的例子來說，我們應(yīng)該把IWorker分離成2個(gè)接口。 搜一下：接口隔離原則適用于哪個(gè)設(shè)計(jì)模式 
2，java語言支持oop中的oop是什么
OOP: Object Oriented Programming,面向?qū)ο蟮某绦蛟O(shè)計(jì)。所謂“對(duì)象”就是一個(gè)或一組數(shù)據(jù)以及處理這些數(shù)據(jù)的方法和過程的集合。面向?qū)ο蟮某绦蛟O(shè)計(jì)完全不同于傳統(tǒng)的面向過程程序設(shè)計(jì)，它大大地降低了軟件開發(fā)的難度，使編程就像搭積木一樣簡(jiǎn)單，是當(dāng)今電腦編程的一股勢(shì)不可擋的潮流。面向?qū)ο缶幊蹋∣bject Oriented Programming，OOP，面向?qū)ο蟪绦蛟O(shè)計(jì)）是一種計(jì)算機(jī)編程架構(gòu)。OOP 的一條基本原則是計(jì)算機(jī)程序是由單個(gè)能夠起到子程序作用的單元或?qū)ο蠼M合而成。OOP 達(dá)到了軟件工程的三個(gè)主要目標(biāo)：重用性、靈活性和擴(kuò)展性。為了實(shí)現(xiàn)整體運(yùn)算，每個(gè)對(duì)象都能夠接收信息、處理數(shù)據(jù)和向其它對(duì)象發(fā)送信息。OOP 主要有以下的概念和組件：組件 － 數(shù)據(jù)和功能一起在運(yùn)行著的計(jì)算機(jī)程序中形成的單元，組件在 OOP 計(jì)算機(jī)程序中是模塊和結(jié)構(gòu)化的基礎(chǔ)。抽象性 － 程序有能力忽略正在處理中信息的某些方面，即對(duì)信息主要方面關(guān)注的能力。封裝 － 也叫做信息封裝：確保組件不會(huì)以不可預(yù)期的方式改變其它組件的內(nèi)部狀態(tài)；只有在那些提供了內(nèi)部狀態(tài)改變方法的組件中，才可以訪問其內(nèi)部狀態(tài)。每類組件都提供了一個(gè)與其它組件聯(lián)系的接口，并規(guī)定了其它組件進(jìn)行調(diào)用的方法。多態(tài)性 － 組件的引用和類集會(huì)涉及到其它許多不同類型的組件，而且引用組件所產(chǎn)生的結(jié)果得依據(jù)實(shí)際調(diào)用的類型。繼承性 － 允許在現(xiàn)存的組件基礎(chǔ)上創(chuàng)建子類組件，這統(tǒng)一并增強(qiáng)了多態(tài)性和封裝性。典型地來說就是用類來對(duì)組件進(jìn)行分組，而且還可以定義新類為現(xiàn)存的類的擴(kuò)展，這樣就可以將類組織成樹形或網(wǎng)狀結(jié)構(gòu)，這體現(xiàn)了動(dòng)作的通用性。由于抽象性、封裝性、重用性以及便于使用等方面的原因，以組件為基礎(chǔ)的編程在腳本語言中已經(jīng)變得特別流行。Python 和 Ruby 是最近才出現(xiàn)的語言，在開發(fā)時(shí)完全采用了 OOP 的思想，而流行的 Perl 腳本語言從版本5開始也慢慢地加入了新的面向?qū)ο蟮墓δ芙M件。用組件代替“現(xiàn)實(shí)”上的實(shí)體成為 JavaScript（ECMAScript）得以流行的原因，有論證表明對(duì)組件進(jìn)行適當(dāng)?shù)慕M合就可以在英特網(wǎng)上代替 HTML 和 XML 的文檔對(duì)象模型（DOM）。 面向?qū)ο缶幊蹋∣bject Oriented Programming，OOP，面向?qū)ο蟪绦蛟O(shè)計(jì)）。 是一種計(jì)算機(jī)編程架構(gòu)。OOP 的一條基本原則是計(jì)算機(jī)程序是由單個(gè)能夠起到子程序作用的單元或?qū)ο蠼M合而成。 三個(gè)過程通常會(huì)相互影響，不是個(gè)簡(jiǎn)單的順序關(guān)系。這種“非順序的關(guān)系”就是軟件過程研究的主要內(nèi)容。ooa通過對(duì)象的思想進(jìn)行用戶業(yè)務(wù)的分析和構(gòu)架，獲得對(duì)象化的分析結(jié)果。ood通過對(duì)象的思想進(jìn)行軟件系統(tǒng)設(shè)計(jì)，獲得對(duì)應(yīng)的詳細(xì)設(shè)計(jì)結(jié)果，可能是文檔化的詳細(xì)設(shè)計(jì)，也可能是模型化的設(shè)計(jì)模型。前兩個(gè)都屬于方法論的范疇，而后者則屬于過程論的范疇。oop是指在軟件開發(fā)過程中通過oo的思想進(jìn)行表達(dá)和實(shí)現(xiàn)。ooa通過對(duì)象的思想進(jìn)行用戶業(yè)務(wù)的分析和構(gòu)架，獲得對(duì)象化的分析結(jié)果。ood通過對(duì)象的思想進(jìn)行軟件系統(tǒng)設(shè)計(jì)，獲得對(duì)應(yīng)的詳細(xì)設(shè)計(jì)結(jié)果，可能是文檔化的詳細(xì)設(shè)計(jì)，也可能是模型化的設(shè)計(jì)模型。前兩個(gè)都屬于方法論的范疇，而后者則屬于過程論的范疇。oop是指在軟件開發(fā)過程中通過oo的思想進(jìn)行表達(dá)和實(shí)現(xiàn)。 面向?qū)ο缶幊蹋∣bject Oriented Programming，OOP，面向?qū)ο蟪绦蛟O(shè)計(jì)）是一種計(jì)算機(jī)編程架構(gòu)。OOP 的一條基本原則是計(jì)算機(jī)程序是由單個(gè)能夠起到子程序作用的單元或?qū)ο蠼M合而成。 面向?qū)ο缶幊蹋∣bject Oriented Programming，OOP，面向?qū)ο蟪绦蛟O(shè)計(jì)）是一種計(jì)算機(jī)編程架構(gòu)。OOP 的一條基本原則是計(jì)算機(jī)程序是由單個(gè)能夠起到子程序作用的單元或?qū)ο蠼M合而成。OOP 達(dá)到了軟件工程的三個(gè)主要目標(biāo)：重用性、靈活性和擴(kuò)展性。為了實(shí)現(xiàn)整體運(yùn)算，每個(gè)對(duì)象都能夠接收信息、處理數(shù)據(jù)和向其它對(duì)象發(fā)送信息。1. 開閉原則 2. 依賴倒轉(zhuǎn)原則3. 里氏代換原則 4. 合成/聚合復(fù)用原則 5. 迪米特原則 6.6. 接口隔離原則 
3，面向?qū)ο蟮奈宕笤瓌t
單一職責(zé)原則 對(duì)于單一職責(zé)原則，其核心思想為：一個(gè)類，最好只做一件事，只有一個(gè)引起它的變化。單一職責(zé)原則可以看做是低耦合、高內(nèi)聚在面向?qū)ο笤瓌t上的引申，將職責(zé)定義為引起變化的原因，以提高內(nèi)聚性來減少引起變化的原因。職責(zé)過多，可能引起它變化的原因就越多，這將導(dǎo)致職責(zé)依賴，相互之間就產(chǎn)生影響，從而大大損傷其內(nèi)聚性和耦合度。通常意義下的單一職責(zé)，就是指只有一種單一功能，不要為類實(shí)現(xiàn)過多的功能點(diǎn)，以保證實(shí)體只有一個(gè)引起它變化的原因。 專注，是一個(gè)人優(yōu)良的品質(zhì)；同樣的，單一也是一個(gè)類的優(yōu)良設(shè)計(jì)。交雜不清的職責(zé)將使得代碼看起來特別別扭牽一發(fā)而動(dòng)全身，有失美感和必然導(dǎo)致丑陋的系統(tǒng)錯(cuò)誤風(fēng)險(xiǎn)。 開放封閉原則 對(duì)于開放封閉原則，它是面向?qū)ο笏性瓌t的核心，軟件設(shè)計(jì)說到底追求的目標(biāo)就是封裝變化、降低耦合，而開放封閉原則就是這一目標(biāo)的最直接體現(xiàn)。 開放封閉原則，其核心思想是：軟件實(shí)體應(yīng)該是可擴(kuò)展的，而不可修改的。也就是，對(duì)擴(kuò)展開放，對(duì)修改封閉的。 因此，開放封閉原則主要體現(xiàn)在兩個(gè)方面：1、對(duì)擴(kuò)展開放，意味著有新的需求或變化時(shí)，可以對(duì)現(xiàn)有代碼進(jìn)行擴(kuò)展，以適應(yīng)新的情況。2、對(duì)修改封閉，意味著類一旦設(shè)計(jì)完成，就可以獨(dú)立完成其工作，而不要對(duì)其進(jìn)行任何嘗試的修改。 實(shí)現(xiàn)開開放封閉原則的核心思想就是對(duì)抽象編程，而不對(duì)具體編程，因?yàn)槌橄笙鄬?duì)穩(wěn)定。讓類依賴于固定的抽象，所以修改就是封閉的；而通過面向?qū)ο蟮睦^承和多態(tài)機(jī)制，又可以實(shí)現(xiàn)對(duì)抽象類的繼承，通過覆寫其方法來改變固有行為，實(shí)現(xiàn)新的拓展方法，所以就是開放的。 “需求總是變化”沒有不變的軟件，所以就需要用封閉開放原則來封閉變化滿足需求，同時(shí)還能保持軟件內(nèi)部的封裝體系穩(wěn)定，不被需求的變化影響。 依賴倒置原則 對(duì)于依賴倒置原則，其核心思想是：依賴于抽象。具體而言就是高層模塊不依賴于底層模塊，二者都同依賴于抽象；抽象不依賴于具體，具體依賴于抽象。 我們知道，依賴一定會(huì)存在于類與類、模塊與模塊之間。當(dāng)兩個(gè)模塊之間存在緊密的耦合關(guān)系時(shí)，最好的方法就是分離接口和實(shí)現(xiàn)：在依賴之間定義一個(gè)抽象的接口使得高層模塊調(diào)用接口，而底層模塊實(shí)現(xiàn)接口的定義，以此來有效控制耦合關(guān)系，達(dá)到依賴于抽象的設(shè)計(jì)目標(biāo)。 抽象的穩(wěn)定性決定了系統(tǒng)的穩(wěn)定性，因?yàn)槌橄笫遣蛔兊?，依賴于抽象是面向?qū)ο笤O(shè)計(jì)的精髓，也是依賴倒置原則的核心。 依賴于抽象是一個(gè)通用的原則，而某些時(shí)候依賴于細(xì)節(jié)則是在所難免的，必須權(quán)衡在抽象和具體之間的取舍，方法不是一層不變的。依賴于抽象，就是對(duì)接口編程，不要對(duì)實(shí)現(xiàn)編程。 接口隔離原則 對(duì)于接口隔離原則，其核心思想是：使用多個(gè)小的專門的接口，而不要使用一個(gè)大的總接口。 具體而言，接口隔離原則體現(xiàn)在：接口應(yīng)該是內(nèi)聚的，應(yīng)該避免“胖”接口。一個(gè)類對(duì)另外一個(gè)類的依賴應(yīng)該建立在最小的接口上，不要強(qiáng)迫依賴不用的方法，這是一種接口污染。 接口有效地將細(xì)節(jié)和抽象隔離，體現(xiàn)了對(duì)抽象編程的一切好處，接口隔離強(qiáng)調(diào)接口的單一性。而胖接口存在明顯的弊端，會(huì)導(dǎo)致實(shí)現(xiàn)的類型必須完全實(shí)現(xiàn)接口的所有方法、屬性等；而某些時(shí)候，實(shí)現(xiàn)類型并非需要所有的接口定義，在設(shè)計(jì)上這是“浪費(fèi)”，而且在實(shí)施上這會(huì)帶來潛在的問題，對(duì)胖接口的修改將導(dǎo)致一連串的客戶端程序需要修改，有時(shí)候這是一種災(zāi)難。在這種情況下，將胖接口分解為多個(gè)特點(diǎn)的定制化方法，使得客戶端僅僅依賴于它們的實(shí)際調(diào)用的方法，從而解除了客戶端不會(huì)依賴于它們不用的方法。 分離的手段主要有以下兩種：1、委托分離，通過增加一個(gè)新的類型來委托客戶的請(qǐng)求，隔離客戶和接口的直接依賴，但是會(huì)增加系統(tǒng)的開銷。2、多重繼承分離，通過接口多繼承來實(shí)現(xiàn)客戶的需求，這種方式是較好的。 Liskov替換原則 對(duì)于Liskov替換原則，其核心思想是：子類必須能夠替換其基類。這一思想體現(xiàn)為對(duì)繼承機(jī)制的約束規(guī)范，只有子類能夠替換基類時(shí)，才能保證系統(tǒng)在運(yùn)行期內(nèi)識(shí)別子類，這是保證繼承復(fù)用的基礎(chǔ)。在父類和子類的具體行為中，必須嚴(yán)格把握繼承層次中的關(guān)系和特征，將基類替換為子類，程序的行為不會(huì)發(fā)生任何變化。同時(shí)，這一約束反過來則是不成立的，子類可以替換基類，但是基類不一定能替換子類。 Liskov替換原則，主要著眼于對(duì)抽象和多態(tài)建立在繼承的基礎(chǔ)上，因此只有遵循了Liskov替換原則，才能保證繼承復(fù)用是可靠地。實(shí)現(xiàn)的方法是面向接口編程：將公共部分抽象為基類接口或抽象類，通過Extract Abstract Class，在子類中通過覆寫父類的方法實(shí)現(xiàn)新的方式支持同樣的職責(zé)。 Liskov替換原則是關(guān)于繼承機(jī)制的設(shè)計(jì)原則，違反了Liskov替換原則就必然導(dǎo)致違反開放封閉原則。 Liskov替換原則能夠保證系統(tǒng)具有良好的拓展性，同時(shí)實(shí)現(xiàn)基于多態(tài)的抽象機(jī)制，能夠減少代碼冗余，避免運(yùn)行期的類型判別。 
4，面向?qū)ο笪屙?xiàng)基本原則
◆ SRP，單一職責(zé)原則，一個(gè)類應(yīng)該有且只有一個(gè)改變的理由。 ◆ OCP，開放封閉原則，你應(yīng)該能夠不用修改原有類就能擴(kuò)展一個(gè)類的行為。 ◆ LSP，Liskov替換原則，派生類要與其基類自相容。 ◆ DIP，依賴倒置原則，依賴于抽象而不是實(shí)現(xiàn)。 ◆ ISP，接口隔離原則，客戶只要關(guān)注它們所需的接口 單一職責(zé)原則 對(duì)于單一職責(zé)原則，其核心思想為：一個(gè)類，最好只做一件事，只有一個(gè)引起它的變化。單一職責(zé)原則可以看做是低耦合、高內(nèi)聚在面向?qū)ο笤瓌t上的引申，將職責(zé)定義為引起變化的原因，以提高內(nèi)聚性來減少引起變化的原因。職責(zé)過多，可能引起它變化的原因就越多，這將導(dǎo)致職責(zé)依賴，相互之間就產(chǎn)生影響，從而大大損傷其內(nèi)聚性和耦合度。通常意義下的單一職責(zé)，就是指只有一種單一功能，不要為類實(shí)現(xiàn)過多的功能點(diǎn)，以保證實(shí)體只有一個(gè)引起它變化的原因。 專注，是一個(gè)人優(yōu)良的品質(zhì)；同樣的，單一也是一個(gè)類的優(yōu)良設(shè)計(jì)。交雜不清的職責(zé)將使得代碼看起來特別別扭牽一發(fā)而動(dòng)全身，有失美感和必然導(dǎo)致丑陋的系統(tǒng)錯(cuò)誤風(fēng)險(xiǎn)。開放封閉原則 對(duì)于開放封閉原則，它是面向?qū)ο笏性瓌t的核心，軟件設(shè)計(jì)說到底追求的目標(biāo)就是封裝變化、降低耦合，而開放封閉原則就是這一目標(biāo)的最直接體現(xiàn)。 開放封閉原則，其核心思想是：軟件實(shí)體應(yīng)該是可擴(kuò)展的，而不可修改的。也就是，對(duì)擴(kuò)展開放，對(duì)修改封閉的。 因此，開放封閉原則主要體現(xiàn)在兩個(gè)方面：1、對(duì)擴(kuò)展開放，意味著有新的需求或變化時(shí)，可以對(duì)現(xiàn)有代碼進(jìn)行擴(kuò)展，以適應(yīng)新的情況。2、對(duì)修改封閉，意味著類一旦設(shè)計(jì)完成，就可以獨(dú)立完成其工作，而不要對(duì)其進(jìn)行任何嘗試的修改。 實(shí)現(xiàn)開開放封閉原則的核心思想就是對(duì)抽象編程，而不對(duì)具體編程，因?yàn)槌橄笙鄬?duì)穩(wěn)定。讓類依賴于固定的抽象，所以修改就是封閉的；而通過面向?qū)ο蟮睦^承和多態(tài)機(jī)制，又可以實(shí)現(xiàn)對(duì)抽象類的繼承，通過覆寫其方法來改變固有行為，實(shí)現(xiàn)新的拓展方法，所以就是開放的。 “需求總是變化”沒有不變的軟件，所以就需要用封閉開放原則來封閉變化滿足需求，同時(shí)還能保持軟件內(nèi)部的封裝體系穩(wěn)定，不被需求的變化影響。依賴倒置原則 對(duì)于依賴倒置原則，其核心思想是：依賴于抽象。具體而言就是高層模塊不依賴于底層模塊，二者都同依賴于抽象；抽象不依賴于具體，具體依賴于抽象。 我們知道，依賴一定會(huì)存在于類與類、模塊與模塊之間。當(dāng)兩個(gè)模塊之間存在緊密的耦合關(guān)系時(shí)，最好的方法就是分離接口和實(shí)現(xiàn)：在依賴之間定義一個(gè)抽象的接口使得高層模塊調(diào)用接口，而底層模塊實(shí)現(xiàn)接口的定義，以此來有效控制耦合關(guān)系，達(dá)到依賴于抽象的設(shè)計(jì)目標(biāo)。 抽象的穩(wěn)定性決定了系統(tǒng)的穩(wěn)定性，因?yàn)槌橄笫遣蛔兊?，依賴于抽象是面向?qū)ο笤O(shè)計(jì)的精髓，也是依賴倒置原則的核心。 依賴于抽象是一個(gè)通用的原則，而某些時(shí)候依賴于細(xì)節(jié)則是在所難免的，必須權(quán)衡在抽象和具體之間的取舍，方法不是一層不變的。依賴于抽象，就是對(duì)接口編程，不要對(duì)實(shí)現(xiàn)編程。接口隔離原則 對(duì)于接口隔離原則，其核心思想是：使用多個(gè)小的專門的接口，而不要使用一個(gè)大的總接口。 具體而言，接口隔離原則體現(xiàn)在：接口應(yīng)該是內(nèi)聚的，應(yīng)該避免“胖”接口。一個(gè)類對(duì)另外一個(gè)類的依賴應(yīng)該建立在最小的接口上，不要強(qiáng)迫依賴不用的方法，這是一種接口污染。 接口有效地將細(xì)節(jié)和抽象隔離，體現(xiàn)了對(duì)抽象編程的一切好處，接口隔離強(qiáng)調(diào)接口的單一性。而胖接口存在明顯的弊端，會(huì)導(dǎo)致實(shí)現(xiàn)的類型必須完全實(shí)現(xiàn)接口的所有方法、屬性等；而某些時(shí)候，實(shí)現(xiàn)類型并非需要所有的接口定義，在設(shè)計(jì)上這是“浪費(fèi)”，而且在實(shí)施上這會(huì)帶來潛在的問題，對(duì)胖接口的修改將導(dǎo)致一連串的客戶端程序需要修改，有時(shí)候這是一種災(zāi)難。在這種情況下，將胖接口分解為多個(gè)特點(diǎn)的定制化方法，使得客戶端僅僅依賴于它們的實(shí)際調(diào)用的方法，從而解除了客戶端不會(huì)依賴于它們不用的方法。 分離的手段主要有以下兩種：1、委托分離，通過增加一個(gè)新的類型來委托客戶的請(qǐng)求，隔離客戶和接口的直接依賴，但是會(huì)增加系統(tǒng)的開銷。2、多重繼承分離，通過接口多繼承來實(shí)現(xiàn)客戶的需求，這種方式是較好的。 liskov替換原則 對(duì)于liskov替換原則，其核心思想是：子類必須能夠替換其基類。這一思想體現(xiàn)為對(duì)繼承機(jī)制的約束規(guī)范，只有子類能夠替換基類時(shí)，才能保證系統(tǒng)在運(yùn)行期內(nèi)識(shí)別子類，這是保證繼承復(fù)用的基礎(chǔ)。在父類和子類的具體行為中，必須嚴(yán)格把握繼承層次中的關(guān)系和特征，將基類替換為子類，程序的行為不會(huì)發(fā)生任何變化。同時(shí)，這一約束反過來則是不成立的，子類可以替換基類，但是基類不一定能替換子類。 liskov替換原則，主要著眼于對(duì)抽象和多態(tài)建立在繼承的基礎(chǔ)上，因此只有遵循了liskov替換原則，才能保證繼承復(fù)用是可靠地。實(shí)現(xiàn)的方法是面向接口編程：將公共部分抽象為基類接口或抽象類，通過extract abstract class，在子類中通過覆寫父類的方法實(shí)現(xiàn)新的方式支持同樣的職責(zé)。 liskov替換原則是關(guān)于繼承機(jī)制的設(shè)計(jì)原則，違反了liskov替換原則就必然導(dǎo)致違反開放封閉原則。 liskov替換原則能夠保證系統(tǒng)具有良好的拓展性，同時(shí)實(shí)現(xiàn)基于多態(tài)的抽象機(jī)制，能夠減少代碼冗余，避免運(yùn)行期的類型判別。 http://www.360doc.com/content/08/0430/19/61497_1226390.shtml 5，面向?qū)ο笤O(shè)計(jì)原則開放封閉原則
面向?qū)ο笤O(shè)計(jì)原則-開放封閉原則，對(duì)于擴(kuò)展是開放的，對(duì)于修改是封閉的。修改（增加）類的成員變量或?qū)傩远际菍儆凇靶薷摹薄U(kuò)展一般是指在原有的架構(gòu)（小一點(diǎn)的說是接口）基礎(chǔ)上進(jìn)行擴(kuò)展。開放封閉原則是指在現(xiàn)有的功能中，不修改原有的代碼中進(jìn)行擴(kuò)展。為符合開放封閉原則，可以利用一些設(shè)計(jì)模式來實(shí)現(xiàn)。如第四副圖，在原有countArea()方法需要增加輸出功能。比如可以使用適配器模式（前提是要面向接口編程）。如下：原先的設(shè)計(jì)是定義一個(gè)接口ISqure,其定義的方法為第四副圖左邊類Squre包含的setLength、countArea方法。第四副圖左邊類Squre實(shí)現(xiàn)了ISqure?？蛻舳苏{(diào)用代碼：ISqure squre = new Square(); (一般不會(huì)這樣直接獲取對(duì)象，如通過工廠方法獲取對(duì)象)；double area = squre.countArea();以上是原有的設(shè)計(jì)現(xiàn)在需要countArea方法中還具有輸出功能，如何在不修改Squre類的情況下做到呢？新建另一個(gè)類SqureImpl,同時(shí)它也實(shí)現(xiàn)接口ISqure，代碼如下：public class SqureAdapter implements ISqure static ISqure squre = new Squre();//原有的代碼中的類Squre public void setLength(double length) squre.setLength(length); } public double countArea() double area = squre.countArea(); System.out.println(area); //增加輸出area return area; }}修改客戶端調(diào)用代碼：ISqure squre = new SqureAdapter(); double area = squre.countArea();這樣達(dá)到了不修改原有Square類，而是通過繼承（擴(kuò)展）接口ISqure，來增加了輸出area的功能。這樣做的好處是維持了原有代碼（功能）的穩(wěn)定性（可能系統(tǒng)的代碼其他地方有很多調(diào)用Square的countArea方法，這樣對(duì)它們是不影響的）。我也是最近在看面向?qū)ο笤O(shè)計(jì)原則的書，有問題或建議請(qǐng)?zhí)岢鰜?，大家共同學(xué)習(xí)。 1，面向?qū)ο笫且环N思考方式（不用考慮哪些定義，就像我問你，漢語的說話方式，大部分人是不會(huì)思考完你要說的話是否符合規(guī)則在說呢，只要記住把所有涉及到的東西看成對(duì)象去編程）例：“一個(gè)人吃飯” 面向過程的思考方式：“第一步，人拿起筷子。第二步，人用筷子夾飯。第三步，人把飯吃掉。第四步，無線循環(huán)第二步第三步，直到飯沒或人吃飽?！? 面向?qū)ο蟮乃伎挤绞剑喝耸且粋€(gè)類，飯是一個(gè)類，飯類中某屬性減少，人類中某屬性增加，飯類中屬性沒有時(shí)，或人類中屬性達(dá)到最大值即吃完。 擴(kuò)展還是修改？ 擴(kuò)展時(shí)什么？不就是增加，往類里面添加就是擴(kuò)展。其實(shí)答案你自己已經(jīng)寫出來了，你 1,2,3,4，里面那個(gè)有添加就是擴(kuò)展。修改不就是改變，改為嘛。擴(kuò)展是開放的，對(duì)于修改是封閉的。就是說 擴(kuò)展你可以無限擴(kuò)，沒有局限。 修改你只能改那類里的東西，類本來就有的屬性。（沒必要記，有些人就喜歡把不需要定義的，硬改成有定義。只要記住把所有涉及到的東西看成對(duì)象去編程） 1、開閉原則（Open Close Principle）：開閉原則就是說對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉。-----在程序需要進(jìn)行拓展的時(shí)候，不能去修改原有的代碼，實(shí)現(xiàn)一個(gè)熱插拔的效果--------。所以一句話概括就是：為了使程序的擴(kuò)展性好，易于維護(hù)和升級(jí)。想要達(dá)到這樣的效果，我們需要使用接口和抽象類?？聪露x：這樣的原則還有很多：2、里氏代換原則（Liskov Substitution Principle）里氏代換原則(Liskov Substitution Principle LSP)面向?qū)ο笤O(shè)計(jì)的基本原則之一。 里氏代換原則中說，任何基類可以出現(xiàn)的地方，子類一定可以出現(xiàn)。 LSP是繼承復(fù)用的基石，只有當(dāng)衍生類可以替換掉基類，軟件單位的功能不受到影響時(shí)，基類才能真正被復(fù)用，而衍生類也能夠在基類的基礎(chǔ)上增加新的行為。里氏代換原則是對(duì)“開-閉”原則的補(bǔ)充。實(shí)現(xiàn)“開-閉”原則的關(guān)鍵步驟就是抽象化。而基類與子類的繼承關(guān)系就是抽象化的具體實(shí)現(xiàn)，所以里氏代換原則是對(duì)實(shí)現(xiàn)抽象化的具體步驟的規(guī)范3、依賴倒轉(zhuǎn)原則（Dependence Inversion Principle）這個(gè)是開閉原則的基礎(chǔ)，具體內(nèi)容：真對(duì)接口編程，依賴于抽象而不依賴于具體。4、接口隔離原則（Interface Segregation Principle）這個(gè)原則的意思是：使用多個(gè)隔離的接口，比使用單個(gè)接口要好。還是一個(gè)降低類之間的耦合度的意思，從這兒我們看出，其實(shí)設(shè)計(jì)模式就是一個(gè)軟件的設(shè)計(jì)思想，從大型軟件架構(gòu)出發(fā)，為了升級(jí)和維護(hù)方便。所以上文中多次出現(xiàn)：降低依賴，降低耦合。5、迪米特法則（最少知道原則）（Demeter Principle）為什么叫最少知道原則，就是說：一個(gè)實(shí)體應(yīng)當(dāng)盡量少的與其他實(shí)體之間發(fā)生相互作用，使得系統(tǒng)功能模塊相對(duì)獨(dú)立。6、合成復(fù)用原則（Composite Reuse Principle）原則是盡量使用合成/聚合的方式，而不是使用繼承。
