欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久

什么叫面向接口編程［作者：umlchina 轉貼自：www.umlchina.com ］

在一個(gè)面向對象的系統中，系統的各種功能是由許許多多的不同對象協(xié)作完成的。在這種情況下，各個(gè)對象內部是如何實(shí)現自己的對系統設計人員來(lái)講就不那么重要了；而各個(gè)對象之間的協(xié)作關(guān)系則成為系統設計的關(guān)鍵。小到不同類(lèi)之間的通信，大到各模塊之間的交互，在系統設計之初都是要著(zhù)重考慮的，這也是系統設計的主要工作內容。面向接口編程我想就是指按照這種思想來(lái)編程吧！實(shí)際上，在日常工作中，你已經(jīng)按照接口編程了，只不過(guò)如果你沒(méi)有這方面的意識，那么你只是在被動(dòng)的實(shí)現這一思想；表現在頻繁的抱怨別人改的代碼影響了你（接口沒(méi)有設計到），表現在某個(gè)模塊的改動(dòng)引起其他模塊的大規模調整（模塊接口沒(méi)有很好的設計）等等。

　　Booch先生那天談到Interaction Designer，它就是指做這類(lèi)設計的人，只不過(guò)層次更高一些。我想目前我們的軟件設計隊伍中，這類(lèi)人是最缺乏的人才之一。
非接口編程？是不是就是面向過(guò)程的編程思想？

　　1.關(guān)于接口的理解。
　　接口從更深層次的理解，應是定義（規范，約束）與實(shí)現（名實(shí)分離的原則）的分離。
　　我們在一般實(shí)現一個(gè)系統的時(shí)候，通常是將定義與實(shí)現合為一體，不加分離的，我認為最為理解的系統設計規范應是所有的定義與實(shí)現分離，盡管這可能對系統中的某些情況有點(diǎn)繁煩。
　　接口的本身反映了系統設計人員對系統的抽象理解。
　　接口應有兩類(lèi)：第一類(lèi)是對一個(gè)體的抽象，它可對應為一個(gè)抽象體(abstract class)；
　　第二類(lèi)是對一個(gè)體某一方面的抽象，即形成一個(gè)抽象面（interface）；
　　一個(gè)體有可能有多個(gè)抽象面。
　　抽象體與抽象面是有區別的。

　　2.設計接口的另一個(gè)不可忽視的因素是接口所處的環(huán)境(context,environment)，系統論的觀(guān)點(diǎn)：環(huán)境是系統要素所處的空間與外部影響因素的總和。任何接口都是在一定的環(huán)境中產(chǎn)生的。因此環(huán)境的定義及環(huán)境的變化對接口的影響是不容忽視的，脫離原先的環(huán)境，所有的接口將失去原有的意義。

　　3.按照組件的開(kāi)發(fā)模型（3C），它們三者相輔相成，各司一面，渾然一體，缺一不可。

　　面向對象是指，我們考慮問(wèn)題時(shí)，以對象為單位，考慮它的屬性及方法
　　面向過(guò)程是指，我們考慮問(wèn)題時(shí)，以一個(gè)具體的流程（事務(wù)過(guò)程）為單位，考慮它的實(shí)現
　　接口設計與非接口設計是針對復用技術(shù)而言的，與面向對象（過(guò)程）不是一個(gè)問(wèn)題

　　我認為：UML里面所說(shuō)的interface是協(xié)議的另一種說(shuō)法。并不是指com的interface，CORBA的interface，Java的interface，Delphi的interface，人機界面的interface或NIC的interface。

　　在具體實(shí)現中，是可以把UML的interface實(shí)現為語(yǔ)言的interface，分布式對象環(huán)境的interface或其它什么interface，但就理解UML的interface而言，指的是系統每部分的實(shí)現和實(shí)現之間，通過(guò)interface所確定的協(xié)議來(lái)共同工作。

　　所以我認為，面向interface編程，原意是指面向抽象協(xié)議編程，實(shí)現者在實(shí)現時(shí)要嚴格按協(xié)議來(lái)辦。也就是BillJoy同志說(shuō)的，一邊翻rfc，一邊寫(xiě)代碼的意思。面向對象編程是指面向抽象和具象。抽象和具象是矛盾的統一體，不可能只有抽象沒(méi)有具象。一般懂得抽象的人都明白這個(gè)道理。 但有的人只知具象卻不知抽象為何物。

　　所以只有interface沒(méi)有實(shí)現，或只有實(shí)現而沒(méi)有interface者是沒(méi)有用的，反OO的。

　　所以還是老老實(shí)實(shí)面向對象編程，面向協(xié)議編程，或者什么都不面向，老老實(shí)實(shí)編程。

　　但是我很討厭討論這樣的術(shù)語(yǔ)，不如我們談?wù)勈裁唇忻嫦蝾I(lǐng)導的編程？面向用戶(hù)的編程？領(lǐng)導和用戶(hù)有時(shí)都很BT，我們就面向BT編程？

選擇Java接口還是抽象類(lèi)

很多人有過(guò)這樣的疑問(wèn)：為什么有的地方必須使用接口而不是抽象類(lèi)，而在另一些地方，又必須使用抽象類(lèi)而不是接口呢？或者說(shuō)，在考慮Java類(lèi)的一般化問(wèn)題時(shí)，很多人會(huì )在接口和抽象類(lèi)之間猶豫不決，甚至隨便選擇一種。

　　實(shí)際上接口和抽象類(lèi)的選擇不是隨心所欲的。要理解接口和抽象類(lèi)的選擇原則，有兩個(gè)概念很重要：對象的行為和對象的實(shí)現。如果一個(gè)實(shí)體可以有多種實(shí)現方式，則在設計實(shí)體行為的描述方式時(shí)，應當達到這樣一個(gè)目標：在使用實(shí)體的時(shí)候，無(wú)需詳細了解實(shí)體行為的實(shí)現方式。也就是說(shuō)，要把對象的行為和對象的實(shí)現分離開(kāi)來(lái)。既然Java的接口和抽象類(lèi)都可以定義不提供具體實(shí)現的方法，在分離對象的行為和對象的實(shí)現時(shí)，到底應該使用接口還是使用抽象類(lèi)呢？

通過(guò)抽象類(lèi)建立行為模型

　　在接口和抽象類(lèi)的選擇上，必須遵守這樣一個(gè)原則：行為模型應該總是通過(guò)接口而不是抽象類(lèi)定義。為了說(shuō)明其原因，下面試著(zhù)通過(guò)抽象類(lèi)建立行為模型，看看會(huì )出現什么問(wèn)題。

　　假設要為銷(xiāo)售部門(mén)設計一個(gè)軟件，這個(gè)軟件包含一個(gè)“發(fā)動(dòng)機”（Motor）實(shí)體。顯然無(wú)法在發(fā)動(dòng)機對象中詳細地描述發(fā)動(dòng)機的方方面面，只能描述某些對當前軟件來(lái)說(shuō)重要的特征。至于發(fā)動(dòng)機的哪些特征是重要的，則要與用戶(hù)（銷(xiāo)售部門(mén)）交流才能確定。

　　銷(xiāo)售部門(mén)的人要求每一個(gè)發(fā)動(dòng)機都有一個(gè)稱(chēng)為馬力的參數。對于他們來(lái)說(shuō)，這是惟一值得關(guān)心的參數?；谶@一判斷，可以把發(fā)動(dòng)機的行為定義為以下行為。

　　行為1：查詢(xún)發(fā)動(dòng)機的馬力，發(fā)動(dòng)機將返回一個(gè)表示馬力的整數。

　　雖然現在還不清楚發(fā)動(dòng)機如何取得馬力這個(gè)參數，但可以肯定發(fā)動(dòng)機一定支持這個(gè)行為，而且這是所有發(fā)動(dòng)機惟一值得關(guān)注的行為特征。這個(gè)行為特征既可以用接口定義，也可以用抽象類(lèi)定義。為了說(shuō)明用抽象類(lèi)定義可能出現的問(wèn)題，下面用抽象類(lèi)建立發(fā)動(dòng)機的行為模型，并用Java方法描述行為1，代碼如下：

 public abstract Motor{            
         abstract public int getHorsepower();            
      }            
 

　　在Motor抽象類(lèi)的基礎上構造出多種具體實(shí)現，例如A型發(fā)動(dòng)機、B型發(fā)動(dòng)機等，再加上系統的其它部分，最后得到1.0版的軟件并交付使用。一段時(shí)間過(guò)去了，現在要設計2.0版的軟件。在評估2.0版軟件需求的過(guò)程中，發(fā)現一小部分發(fā)動(dòng)機是電池驅動(dòng)的，而電池需要一定的充電時(shí)間。銷(xiāo)售部門(mén)的人希望能夠通過(guò)計算機查閱充電時(shí)間。根據這一要求定義一個(gè)新的行為，如圖1所示。

　　行為2：查詢(xún)電驅動(dòng)發(fā)動(dòng)機的充電時(shí)間，發(fā)動(dòng)機將返回一個(gè)表示充電時(shí)間的整數。

　　用Java方法來(lái)描述這個(gè)行為，代碼如下：

 public abstract BatteryPoweredMotor extends Motor{            
        abstract public int getTimeToRecharge();            
      }            
 

　　在銷(xiāo)售部門(mén)的軟件中，電驅動(dòng)發(fā)動(dòng)機也以類(lèi)的形式實(shí)現，但這些類(lèi)從BatteryPoweredMotor而不是Motor派生。這些改動(dòng)加入到2.0版軟件之后，銷(xiāo)售部門(mén)很滿(mǎn)意。隨著(zhù)業(yè)務(wù)的不斷發(fā)展，不久之后光驅動(dòng)的發(fā)動(dòng)機出現了。銷(xiāo)售部門(mén)要求光驅動(dòng)發(fā)動(dòng)機需要一定光能才能運轉，光能以流明（Lumen）度量。這個(gè)信息對客戶(hù)很重要，因為下雨或多云的天氣里，某些光驅動(dòng)發(fā)動(dòng)機可能無(wú)法運轉。銷(xiāo)售部門(mén)要求為軟件增加對光驅動(dòng)發(fā)動(dòng)機的支持，所以要定義一個(gè)新的行為。

　　行為3：查詢(xún)光驅動(dòng)發(fā)動(dòng)機能夠正常運轉所需要的最小流明數，發(fā)動(dòng)機返回一個(gè)整數。

　　再定義一個(gè)抽象類(lèi)并把行為3轉換成Java方法，代碼如下：

 public abstract SolarPoweredMotor extends Motor{            
         abstract public int getLumensToOperate();            
      }

　　如圖1所示，SolarPoweredMotor和BatteryPoweredMotor都從Motor抽象類(lèi)派生。在整個(gè)軟件中，90％以上的代碼以相同的方式對待所有的發(fā)動(dòng)機。偶爾需要檢查一下發(fā)動(dòng)機是光驅動(dòng)還是電驅動(dòng)，使用instanceof實(shí)現，代碼如下：

 if (instanceof SolarPoweredMotor){...}            
         if (instanceof BatteryPoweredMotor){...}

　　無(wú)論是哪種發(fā)動(dòng)機，馬力這個(gè)參數都很重要，所以在所有派生的抽象類(lèi)（SolarPoweredMotor和BatteryPoweredMotor）中，getHorsepower()方法都有效。

　　現在銷(xiāo)售部門(mén)又有了一種新的發(fā)動(dòng)機，它是一種既有電驅動(dòng)又有光驅動(dòng)的雙重驅動(dòng)發(fā)動(dòng)機。光驅動(dòng)和電驅動(dòng)的行為本身沒(méi)有變化，但新的發(fā)動(dòng)機同時(shí)支持兩種行為。在考慮如何定義新型的光電驅動(dòng)發(fā)動(dòng)機時(shí)，接口和抽象類(lèi)的差別開(kāi)始顯示出來(lái)了。新的目標是在增加新型發(fā)動(dòng)機的前提下盡量少改動(dòng)代碼。因為與光驅動(dòng)發(fā)動(dòng)機、電驅動(dòng)發(fā)動(dòng)機有關(guān)的代碼已經(jīng)過(guò)全面的測試，不存在已知的Bug。為了增加光電驅動(dòng)發(fā)動(dòng)機，要定義一個(gè)新的SolarBatteryPowered抽象類(lèi)。如果讓SolarBatteryPowered從Motor抽象類(lèi)派生，SolarBatteryPowered將不支持針對光驅動(dòng)發(fā)動(dòng)機和電驅動(dòng)發(fā)動(dòng)機的instanceof操作。也就是說(shuō)，如果查詢(xún)一個(gè)光電驅動(dòng)的發(fā)動(dòng)機是光驅動(dòng)的，還是電驅動(dòng)的，得到的答案是：都不是。

　　如果讓SolarBatteryPowered從SolarPoweredMotor（或BatteryPoweredMotor）抽象類(lèi)派生，類(lèi)似的問(wèn)題也會(huì )出現，SolarBatteryPowered將不支持針對BatteryPoweredMotor（或SolarPoweredMotor）的instanceof操作。從行為上看，光電驅動(dòng)的發(fā)動(dòng)機必須同時(shí)從兩個(gè)抽象類(lèi)派生，但Java語(yǔ)言不允許多重繼承。之所以會(huì )出現這個(gè)問(wèn)題，根本的原因在于使用抽象類(lèi)不僅意味著(zhù)定義特定的行為，而且意味著(zhù)定義實(shí)現的模式。也就是說(shuō)，應該定義一個(gè)發(fā)動(dòng)機如何獲得行為的模型，而不僅僅是聲明發(fā)動(dòng)機具有某一個(gè)行為。

通過(guò)接口建立行為模型

　　如果用接口來(lái)建立行為模型，就可以避免隱含地規定實(shí)現模式。例如，前面的幾個(gè)行為改用接口定義如下。

　　行為1：

 public interface Motor(){            
        public int getHorsepower();            
      }            
 

行為2：

            
public interface BatteryPoweredMotor extends Motor(){            
  public int getTimeToRecharge();            
}

行為3：

            
public interface SolarPoweredMotor extends Motor{            
  abstract public int getLumensToOperate();            
}

　　現在光電驅動(dòng)的發(fā)動(dòng)機可以描述為：

            
public DualPoweredMotor implements SolarPoweredMotor, BatteryPoweredMotor{}            

　　DualPoweredMotor只繼承行為定義，而不是行為的實(shí)現模式，如圖2所示。

　　在使用接口的同時(shí)仍舊可以使用抽象類(lèi)，不過(guò)這時(shí)抽象類(lèi)的作用是實(shí)現行為，而不是定義行為。只要實(shí)現行為的類(lèi)遵從接口定義，即使它改變了父抽象類(lèi)，也不用改變其它代碼與之交互的方式。特別是對于公用的實(shí)現代碼，抽象類(lèi)有它的優(yōu)點(diǎn)。抽象類(lèi)能夠保證實(shí)現的層次關(guān)系，避免代碼重復。然而，即使在使用抽象類(lèi)的場(chǎng)合，也不要忽視通過(guò)接口定義行為模型的原則。從實(shí)踐的角度來(lái)看，如果依賴(lài)于抽象類(lèi)來(lái)定義行為，往往導致過(guò)于復雜的繼承關(guān)系，而通過(guò)接口定義行為能夠更有效地分離行為與實(shí)現，為代碼的維護和修改帶來(lái)方便。

Java接口特性學(xué)習
在Java中看到接口，第一個(gè)想到的可能就是C++中的多重繼承和Java中的另外一個(gè)關(guān)鍵字abstract。從另外一個(gè)角度實(shí)現多重繼承是接口的功能之一，接口的存在可以使Java中的對象可以向上轉型為多個(gè)基類(lèi)型，并且和抽象類(lèi)一樣可以防止他人創(chuàng )建該類(lèi)的對象，因為接口不允許創(chuàng )建對象。

interface關(guān)鍵字用來(lái)聲明一個(gè)接口，它可以產(chǎn)生一個(gè)完全抽象的類(lèi)，并且不提供任何具體實(shí)現。interface的特性整理如下：

1. 接口中的方法可以有參數列表和返回類(lèi)型，但不能有任何方法體。

2. 接口中可以包含字段，但是會(huì )被隱式的聲明為static和final。

3. 接口中的字段只是被存儲在該接口的靜態(tài)存儲區域內，而不屬于該接口。

4. 接口中的方法可以被聲明為public或不聲明，但結果都會(huì )按照public類(lèi)型處理。

5. 當實(shí)現一個(gè)接口時(shí)，需要將被定義的方法聲明為public類(lèi)型的，否則為默認訪(fǎng)問(wèn)類(lèi)型，Java編譯器不允許這種情況。

6. 如果沒(méi)有實(shí)現接口中所有方法，那么創(chuàng )建的仍然是一個(gè)接口。

7. 擴展一個(gè)接口來(lái)生成新的接口應使用關(guān)鍵字extends，實(shí)現一個(gè)接口使用implements。

interface在某些地方和abstract有相似的地方，但是采用哪種方式來(lái)聲明類(lèi)主要參照以下兩點(diǎn)：

1. 如果要創(chuàng )建不帶任何方法定義和成員變量的基類(lèi)，那么就應該選擇接口而不是抽象類(lèi)。

2. 如果知道某個(gè)類(lèi)應該是基類(lèi)，那么第一個(gè)選擇的應該是讓它成為一個(gè)接口，只有在必須要有方法定義和成員變量的時(shí)候，才應該選擇抽象類(lèi)。因為抽象類(lèi)中允許存在一個(gè)或多個(gè)被具體實(shí)現的方法，只要方法沒(méi)有被全部實(shí)現該類(lèi)就仍是抽象類(lèi)。

以上就是接口的基本特性和應用的領(lǐng)域，但是接口絕不僅僅如此，在Java語(yǔ)法結構中，接口可以被嵌套，既可以被某個(gè)類(lèi)嵌套，也可以被接口嵌套。這在實(shí)際開(kāi)發(fā)中可能應用的不多，但也是它的特性之一。需要注意的是，在實(shí)現某個(gè)接口時(shí)，并不需要實(shí)現嵌套在其內部的任何接口，而且，private接口不能在定義它的類(lèi)之外被實(shí)現。