程式設計依賴抽象

依賴於抽象而不依賴與實現，並不難理解。

比方說我們需要乙個東西來盛水，這個東西只要有盛水的功能就行了，我們並不關心它是馬克杯，樂扣杯，或者是解放牌大瓷缸，甚至是尿壺，這個能盛水的東西便是抽象(我們在腦海裡只有乙個概念，卻沒有實物)，而馬克杯或者其他的具體實物便是抽象的實現，面向抽象程式設計會非常靈活，並且低耦合，易於擴充套件和維護，還是那個比方，人是乙個類，人有乙個喝水的方法，想喝水就要依賴乙個能盛水的容器，如果我要是依賴於具體程式設計，比如我今天想用樂扣杯盛水喝，明天想換個口味用尿壺，那麼我就得每天都換一種（換一種實現就得修改一會類），非常麻煩，如果我依賴抽象（介面），我只是想喝水，只要這東西能盛水就行，我需要什麼具體容器，就由它人來提供（工廠類提供乙個具體實現的向上轉型也就是抽象以便喝水的人可以用），來實現解耦

上面是很經典的解釋，但在實際情況下，一般乙個介面操作乙個實體表或多個，依賴很多個業務邏輯層的類，業務改動，必須要去對應的業務邏輯層修改或增加方法。這種情況下，依賴抽象和依賴實現區別不大，這是我的感覺。但在資料訪問層依賴抽象還是很有用的，在切換資料庫的時候。