多用組合少用繼承中，介面繼承算不算一種組合？

1樓：聶同學

繼承也是一種組合，是特殊的有限制的一種。

「多用組合少用繼承」談的是一種能力實現的手段。

介面和抽象類在實際應用中如何選擇？

2樓：正怒月神

歸根結底，還是沒有明白基類（不一定非要抽象類）和介面的區別。

介面在某種意義上，解決多繼承的問題。

但我的理解，更多的是從內涵上區分它們的意義。

基類：泛指乙個型別，它們具備的基礎特徵和行為。

介面：一些功能，但不是所有子類都具備。

我們就假設，有乙個基類：鳥

特徵/屬性：有嘴，有鼻子，有翅膀

行為/方法:吃飯，喝水。。。。。

那麼子類來了：大雁，企鵝，鴿子。

大雁：我要遷移了，你們走不走？

企鵝：大哥，我不怕冷，這麼冷的天我都游泳，你認為我需要去南方？！

鴿子：大哥，我等不到遷移，就被下鍋了。所以我不知道有沒有這個能力。

大雁的遷移，是不是要單獨去實現介面？

（一般，我們會在大雁的上面在建立乙個抽象類繼承自乙個遷移介面）然後通過這個抽象類，去實現大雁，燕子等等的候鳥一樣的道理，企鵝和鴿子，也會有不同的抽象類來實現特定介面。

3樓：靈劍

去弄懂這個根本上的原理，不要去依賴這種二級結論，你信這些教條跟信中醫沒啥區別。組合優於繼承的原因在於組合首先能保持兩個模組之間的解耦，保證被組合的元件仍然有足夠高的抽象性；其次，組合可以封閉被組合元件的對外介面到內部。而繼承通常會大量暴露被繼承元件的內部細節，同時也暴露被繼承元件之前的對外介面，因此如果組合和繼承都可以使用，一般應該優先組合，因為這說明你用被組合元件的公開介面就足以實現邏輯；反過來，如果的確要動用內部邏輯，那可能繼承是合適的（也可能當時的介面設計不合理）。

你implement乙個介面，既不涉及內部實現，又本來就是為了宣告自己有相同的公開介面，哪有上面說的問題啊？

4樓：逍遙的碼農

可能你說的是物件導向設計原則中的組合復用原則！如果A is B用繼承，A has B用組合，這是兩種不同的情況，不能相互比較。這個原則的原意是很多情況下我們總是把has B的情況理解為Is B以至於濫用了繼承，這裡只涉及到合理使用組合，並沒有多用組合的意思！

5樓：co lin

所有問題拋開具體的應用場景都是沒法準確回答的。

拿我熟悉的遊戲伺服器領域來說，以前用得很多的模式是：把遊戲中一切事物抽象為實體(基類)，從實體繼承下來的有場景，角色，掉落物等等；從角色繼承下來的有怪物，玩家，NPC等等，由此形成乙個繼承樹。是不是覺得很自然？

但現在慢慢不這麼做了，因為通過繼承很難把功能很好的切分，比如怪物有技能，玩家也有技能；怪物有AI，NPC也有AI；如果仍然使用繼承的方式，要麼角色類包含所有這些函式介面，然後子類具體實現；要麼再分子類，比如帶AI的角色，帶技能的角色，然後再從這些子類繼承出怪物。。。，最終你會發現整個繼承樹很深很複雜。

現在的做法是元件化：

一切遊戲物件仍然叫實體，但它已沒有具體的邏輯，它只負責管理元件。

每種元件實現具體的功能，比如技能元件，AI元件，序列化元件。。。

將不同的元件整合到不同的實體上，就形成不同的遊戲物件。比如怪物實體，它有技能元件，有AI元件，有位置元件。玩家實體有技能元件，有序列化元件，有與客戶端通訊的網路元件。。

通過元件化，伺服器構架的靈活性大大提高了，你說這算不算一種組合的優點呢？

上面是多用組合少用繼承的回答，另乙個是：介面繼承算不算一種組合？

不算，介面繼承這個聽著有點怪怪的，叫介面實現比較好吧？指明實現該介面的類需要實現的函式集，算是一種契約吧。

6樓：BOT Man

繼承和組合不是一回事吧。。。

組合的物件也不一定要多型，所以也沒必要做成介面。。。

「組合優於繼承」是「字段/屬性」，而不是「介面/繼承」。。。

7樓：黃亮anthony

是，但不必要。

展開一點說，介面繼承解決部分組合的場景，特別是每個介面只有乙個組合物件的情況。但是顯然它解決不了所有組合的情況，所以介面繼承不能取代組合。

解決問題的方案有很多，各有優劣。沒有說一定要用哪一種取代另一些。說多用組合少用繼承，而不是說只用組合不用繼承。

常用的例子：Rect有兩個Point，它就不用能介面繼承解決。同時它也沒有標誌歸一的問題，因為Point一般是值語義。

另外，概念用於交流，同乙個概念應該在兩個說話人之間達成共識。把乙個概念看成另乙個概念只適合於自己理解，不適合交流。組合就是成員和屬性聚合，介面繼承就是繼承，這是比較廣泛的共識，不建議重新定義。

多用組合少用繼承中，介面繼承算不算一種組合？

Collection介面為什麼不直接繼承Iterator介面？

有關Java中類的繼承中方法繼承的問題？

C 中私有繼承跟保護繼承到底有多大用？

其他用戶還看了：