java里面的接口到底的存在的意義是什么啊!


接口到底有什么使用價值啊!
我覺得沒有接口也一樣編程啊,只是麻煩一點,比較容易忘記類之間的聯系罷了!

104 个解决方案

#1


這是面象對象設計的需要,如果一個類要具有多個父類的屬性,就要用到接口,因為java不象c++那樣可以多重繼承
比如:
class AFrame extends JFrame implements ActionListener {

}
AFrame 繼承了JFrame的屬性,方法,同時也要實現ActionListener接口的方法用來進行事件控制,如果ActionListener不是一個接口,而是一個類,就做不到這一點,因為在java中你不可以寫:
class AFrame extends JFrame,ActionListener {

}

#2


"我覺得沒有接口也一樣編程啊"可以這么說,沒錯,不過有了接口才真正的使JAVA擺脫了不能多層繼承的尷尬!

#3


有了接口才真正的使JAVA擺脫了不能多層繼承的尷尬! ---  話沒有錯,但是不可以自己去擴沖一個類嗎?反正接口里的的方法還要自己去實現的。

#4


那有了接口你不覺得方便了項目的管理嗎!?
比如在一個多語言的網站中,需要根據用戶使用的語言不同來使用不同的頁,這時候需要轉換編碼方式的函數,(假如每個小組開發一種語言部分)編碼轉換的函數在JAVA BEAN 中如果每個小組在BEAN中的轉化函數名字都不一樣就為以后的程序維護增添很多的麻煩,而如果用了接口呢大家的BEAN都繼承這個接口只需要重寫方法就可以了方法名也不就統一了嗎?!
當然這個例子並不能完全說明借口的優勢,但就憑這一點我們也應該看到了借口的價值了,不是嗎?!

#5


我們可以全部都用抽象類,但這樣就沒法多重繼承並且系統不夠靈活。
在《hinking in java》里有句話“盡可能地使用接口(相對抽象類)”

#6


我覺得最重要的原因不是為了多重繼承!
過多地使用多重繼承會使問題無限復雜化,應該少用
這也是Java沒有多重繼承的原因,雖然利用接口可以變相地實現多重繼承
我認為真正的原因是為了"上溯造型"!使接口的子類能夠接收和處理父類的消息
從而能夠被接口對象的一個實例調用,不用去關心子類的具體類型。
我說的不是很清楚,不過這在"Thinking In Java"里有非常清楚的解釋,可以去看看

#7


接口是實現回調函數的好方法..

#8


多重繼承吧?

#9


同意magiccode(magiccode)的觀點

#10


從設計可重用的程序來談,更多的使用接口要比繼承更好。

對接口的繼承體現不同的實現,在出現修改需求的時候只需要增加新的類實現原來的接口就行了,而在繼承中往往會涉及多個類的修改。

#11


管理上是方便了  但是沒有接口從技術上說也不是不可以

#12




俺做framework
程序中只有Interface沒有class

#13


回復人: samwong(啊曲) (2002-2-2 20:01:47)  得0分 
接口是實現回調函數的好方法..  


是這樣嗎??不是,我認為內部類才是解決C++中callback的(因為在java中沒有函數指針。)

#14


大家都說到了interface能應用到的許多地方了。
可能更多的用OO的思想編程的人,才能更深體會到interface的妙處!
http://www.artima.com/interfacedesign/index.html

學習中..

#15


這到也是  偶考noi的時候只有面向結構  沒有OO 

#16


to: aprim(四楞子)
天呀..這里是Java論壇..請你多了解java吧!!!
我想先說:java中雖然沒有函數指針的概念引入..但是指針是存在的.
就是我們說的對象的方法.對象本身是引用的.也就是指針的概念.

Javak中,接口是實現回調函數的首選方式之一.我想用一個例子來說; 這是摘自Java2核心技術Volume I.

class Timer extends Thread
  {...
    {public void run()
      {while (true)
       {   sleep(delay);
           //now what?
        }
      }
   }

interface TimerListener
{public void timeElapsed(Timer t);
}

class AlarmClock implements TimerListener
{AlarmClock()
{Timer t=nre Timer(this);
t.setDelay(1000);//1000 milliseconds
}
public void timeElapsed(Timer t)
{ if(t.getTime()>=wakeUpTime)
  wakeUp.play();
}
}

class Timer extends Thread 
{Timer(TimerListener t){listener =t;}
...
pubilc void run()
{while (true)
{sleep(interval);
listener.timeElapsed(this);
}
}
TimerListener listener;
}

Timer類構建器收到對指定對象的引用,並把它保存在listener變量中.每當既定時間一過,其timeElapsed()方法就會被調用.因為listener對象實現了TimerListener接口,編譯器就會知道自已支持的是一個timeElapsed方法.

有關細節請參考"Java2核心技術Volume I" page 163.

 

#17


關注

#18


to:samwong(啊曲)我們現在討論的可不是接口怎么用,而是討論接口有什么用!在你貼上來的程序中把TimerListener接口換成抽象類也是可以的,不是嗎?對了,另外提醒你,JAVA中可沒有回調函數的說法,好象只有回溯哦!
to:magiccode你說的情況在抽象類中也是可以的,所以不具有代表性!(抽象類中也可以實現,回溯哦!)
其實,大家可以把接口看做是比抽象類,還要抽象的對象!(什么方法都沒有實現,只是定義了方法體,而抽象類至少還可以定義點方法!)

#19


關注!

#20


to : pengji(彭乃超) 
你的說法有偏差。
1、java中是有回調的。
2、從極端的角度講,接口使得程序間的耦合度更小,而抽象類是已經定義過方法的,從抽象類基稱,就使你需要改變的方法難免會和其他的已定義的方法相牽連。會造成擴展和改動的不便。(當然,不是說extends就不好。很多時候抽象類都是很需要的)

#21


接口他定義了一個標准,通過其不通的實現類,來實現多態的目的。

#22


to:judgement_sword(沒什么)
1,謝謝,確實有回調
2,從抽象類基稱,就使你需要改變的方法難免會和其他的已定義的方法相牽連。會造成擴展和改動的不便。那如果我寫的抽象類中的方法都為抽象的呢!?不就和接口一樣了嗎?!還會造成擴展和改動的不便嗎?!

#23


g z

#24


面向對象編程中,真正是
對接口編程,而不是對類或對象編程。

#25


學習

#26


提出這樣的問題的同志,
我不得不說你對oop幾乎沒有什么概念!
你去看看<design parttens>,
問題迎刃而解。

#27


對程序設計帶來了很大靈活性 
"對接口編程"是面向對象設計(OOD)的第一個基本原則 
簡單的說,接口就是方法的名字,一個對象跟外界交流的窗口 
也就代表了一個對象有什么功能。 

應用中,你可以把接口當成對象傳給需要使用這個對象的代碼, 
那么這些代碼就可以操縱這個對象了,當你對這個對象的版本不太滿意了 
你就只修改這個對象得了,接口不變,方法名字不變,那么外面的代碼幾乎 
可以完全不變就重用了這個對象。 
"將可變的部分和不可變的部分分離"是面向對象設計的又一個原則 
使用接口你就可以把對象之間的耦合性降低,得到對象的重用性 

#28


當你的項目需要在中國和美國同時開始編程的時候,你就會發現接口的重要性了。
當然,不使用interface也可以實現按接口編程,只要大家約定好,不過這樣的話對子系統的測試會有不良的影響。
另外,不知道有多少人在實際的項目里面用到了多重繼承,不要舉書本上的公雞母雞公母雞。

#29


請問,C++沒有接口,若OOD,那只能用虛類和多重繼承了?

#30


實現 人妖類 呵呵

#31


接口是一種實現多重繼承的妥協的方法.
雖然java的單一繼承有它的好處,但這個好處馬上就會顯得尷尬.
是,不錯,java鼓勵我們在作設計,實現時面向接口,面向對象也是這樣提倡的.
但要知道,最后我們還是要做實現.
舉一個例子,企業有人員,我們叫A類.駕駛員我們叫B類,
那你如何來表示企業駕駛員呢?
如果我們認為A,B是接口,好,面向接口編程嗎,C implements A,B就行了.
可我們現在要做實現呀,同志們.

最后的這個C你准備怎么做呢?
C extends A ,然后再把B的方法加進來 / C extends B,然后再把A的方法加進來
還是..

我准備放棄java了

#32


咦??

直接 C implements A,B 不就可以了嗎??

然后在 C 中實現 A 和 B 的方法。

這樣就實現了啊……

有什么問題??

JAVA挺好的,我不准備放棄它^_^

#33


支持GFox(小狐)

#34


菜鳥就是菜鳥,沒什么好解釋的。

#35


接口和多繼承本來就不是一回事。
多繼承有利有弊,java中不支持多繼承。

接口的目的是為了將定義和實現分離,
這是個很重要的概念,可以看看設計模式。

象回調函數這類動功能也最好由接口來實現。
一個類可以實現多個接口,
這在一定程度上解決了沒有多繼承的問題
但接口在java中絕不是為了彌補多繼承的問題而加入的。

#36


繼續關注

#37


接口很好,看一下SUN推出的WebService中的東西就知道了。
在JAXM和JAXP中公開的全部是接口,而不是實現!!
這里的接口絕不是為了多繼承,也不是為了回調函數!!!!

#38


在整個面向對象設計領域所遵循的一個設計原則:針對接口編程,而不是針對具體的實現。這個思想可以說是設計模式的基石之一。現在的很多對象模型,比如EJB,COM+等等,無不是遵照這個基本原則來設計的。針對接口編程的好處有很多,通過接口來定義對象的抽象功能,方便實現多態和繼承;通過接口來指定對象調用之間的契約,有助於協調對象之間的關系;通過接口來划分對象的職責,有助於尋找對象,等等。

#39


在整個面向對象設計領域所遵循的一個設計原則:針對接口編程,而不是針對具體的實現。這個思想可以說是設計模式的基石之一。現在的很多對象模型,比如EJB,COM+等等,無不是遵照這個基本原則來設計的。針對接口編程的好處有很多,通過接口來定義對象的抽象功能,方便實現多態和繼承;通過接口來指定對象調用之間的契約,有助於協調對象之間的關系;通過接口來划分對象的職責,有助於尋找對象,等等。

#40


在整個面向對象設計領域所遵循的一個設計原則:針對接口編程,而不是針對具體的實現。這個思想可以說是設計模式的基石之一。現在的很多對象模型,比如EJB,COM+等等,無不是遵照這個基本原則來設計的。針對接口編程的好處有很多,通過接口來定義對象的抽象功能,方便實現多態和繼承;通過接口來指定對象調用之間的契約,有助於協調對象之間的關系;通過接口來划分對象的職責,有助於尋找對象,等等。

#41


所謂的針對接口編程.我們可以理解為是在做設計.
但我想再重申一次,我們最后要做的是實現.
按照 GFox(小狐) 所說的,那A,B的方法我並沒有任何方法去重用.
我以為會有人回答說 用聚合而不用繼承.可是沒有.
但你有機會遇到這類問題時,你就會發現"面向接口編程"是如此的使你處在一個尷尬的境地.

#42


那是因為你在不該用接口的地方用了接口。
請看看《設計模式》即《design patern》

不要把眼光局限在一個很小的程序上,
在那么小的東西里,連類都多余,不用說什么接口了。

#43


biti_9512207(波波斯基):
正如leolee(歷歷)所說,這不是Java定義接口造成的,而是Java不支持多重繼承所造成的。
我認為,為了這個原因放棄Java是不值得的,因為多花10分鍾敲擊鍵盤比多花3小時檢查access violation總要划算,如果你沒有對性能的苛刻要求的話。

#44


Yeah

#45


STUDY

#46


波波斯基,
你完全可以復用A B 的方法。
在很多情況下,繼承並不是好的復用代碼的方法,多重繼承就更不是了。

#47


組件化,EJB,com,dcom。。。這些東西研究一下,你就會發現,沒有接口是萬萬不能的,他是組件化實現的基本手段

#48


接口的作用不在於多重繼承的實現。
接口定義了一組規范的服務,不只是java使用接口,corba和com都是使用接口定義語言idl用於定義組件提供的服務。有了預先定義好的接口,不同的服務提供商(spi)可以用不同的方法實現接口,而對於使用服務的程序來說並不需要知道spi的具體實現。很多specification都已接口的方式定義了一組服務,如ldap,xml dom,java jndi

#49


假如繼承是為了實現的話,我的看法是不值得將這個作為選擇語言的出發點。正如你所說的,有很多辦法可以解決這個問題,而這個問題又和interface沒有什么關系。

#50


upuupupupup

注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com