如何理解「在面向對象編程的時候，方法或者函數的參數最好是介面或者抽象類」？

01-27

意思是，比起直接傳一個class，還是傳interface更好。C++沒有interface，因此用抽象類代替。這並不是讓你用interface來代替int啊string這些東西。

贊同 @vczh的回答。

介面、抽象類，可以看作是對某一類的對象、事物的抽象，約定了這一類事物都應該實現的行為。

當我們設計函數的參數時，目的其實是為了調用該類事物的某一個或者某幾個行為，那麼傳遞介面或者抽象類，就是側重於對目標行為的選擇，而不是具體是哪一類對象，屏蔽了部分的細節。

比如，某個一個函數，是向一個stream裡面輸出，那麼參數選擇 ostream ，要好過於 stringstream、fstream這種更為具體的對象。

我認為你引用的這句話是錯的，因此不存在「如何理解」的問題。

你能不能把出處和上下文貼出來？

在編程中有一個重要的概念是依賴。

技術層面而言，依賴是指你依賴的對象如果改變，你的代碼需要隨之改變。沒人喜歡動不動改代碼，有時候更是不可能的事情，所以要盡量減少依賴關係。參數傳遞就是很常見的一種依賴關係。

可是函數，代碼都是層層調用，怎麼能減少甚至消除呢？

很多編程技術就是就致力於解決這個問題。

歸根到底的思想是，能容忍依賴某個符號（或叫做變數名等），但對這個符號的具體解釋，怎樣關聯到具體代碼，編譯和連接系統幫你自動完成。

這個符號就是所謂的抽象的東西。不管它的具體解釋怎麼改動，你的代碼是不需要改動的。

在一本超級棒的書中，作者認為依賴倒置法則是整個 OO 的核心：

上層模塊不依賴底層模塊，它們都要依賴於抽象
抽象不依賴於細節，而細節要依賴於抽象。

在 C 裡面這就是回調函數，C++ 裡面是（純）虛函數，Java 裡面是介面。

這不是理論，而是實踐的經驗。

讓你（盡量）免於因混亂的需求變化而修改代碼引入bug的恐懼。

面向介面編程。介面是協議的實現。在設計函數的時候，只按照協議來設計功能，而不細緻考慮具體的實現，這有利於解耦，應對變化。

在調用這個函數的時候再傳入一個具體的對象，其實調用者的行為改變不會影響函數設計者的行為。

這樣做的目的是減少函數自身模塊對外部的依賴，函數的參數類型越簡單，越抽象，意味著對參數類型的依賴越小，函數內部就越不需要關注參數的類型細節。

其實他的意思是使用那個類的父類引用或者是那個類所實現或者說是繼承的介面的引用，因為這樣有利於後續程序的擴展，就是實現多態這種東西。

比如

class A：B｛｝

則實力化A時候最好是B *pB = new A

其實這就是為了實現多態，當你要在擴展程序時候久很容易，多寫寫程序你就有體會了。

儘可能地面向抽象編程，靈活性更大