面向對象和設計模式都是大家耳熟能詳的概念。面向對象是以對象為基本元素，對數據與邏輯行為進行封裝。實現面向對象過程的方法是使用抽象，同時在使用抽象進行分析設計的時候就產生了類型，并隔離了抽象與實現。這個過程是有很多的優點的，熟話說得好，完美的東西肯定也有不足。因此我們這里要討論的是面向對象的缺點，以及設計模式就是用來彌補這些缺陷的方法總結。

?

抽象是特殊到一般的過程。在這個過程中會忽略對象的個性而歸納出共性。不過對象實例在行為上不僅僅有共性，還有一些自己的特性。如何繼承共性，保持自己的個性也一直是面向對象編程需要實際結局的問題。

?

抽象是靈丹也帶來如何創建具體實現的問題

面向對象使得對象有抽象與實現之分，并在實現中變化，而用抽象來應對變化（也就是抽象是不變這個假設）。首先實現有不同的具體實現，那么在運行時候需要采用哪種手段呢？在面向對象理論里面我沒有找到與之對應的方法，反而在設計模式-創建型的模式里面比如抽象工廠等中找到創建產品具體實現。

?

對象類型帶來的苦惱

由于抽象，對象實例與對象類型以及對象類型之上的泛型化的對象類型，產生了很多的對象類型層次。所以在實現的過程中需要判斷具體的對象類型，根據具體的對象類型來調用相應的操作。而且這在C++里面還有一種專門的RTTI-也就是動態類型診斷技術。在C#里面運行時CLR里面也有TypeChecker這個組件。這種需要判斷類型來進行交互的邏輯實現在對象理論里面也沒有具體的方法。雖然多態方法能根據運行時的類型來動態決定那個具體的函數被調用，但是總是有些地方的邏輯是需要類型判斷的。所以設計模式里面就有了相應的一些模式來彌補面向對象的不足。比如說每種對象類型都都封裝自己的處理邏輯，然后借助反射來實現客戶端與具體類型的解耦。

?

對象實例如何體現個性

對象實例是對象在運行時態的一個視圖，由于我們使用面向對象的繼承機制，所以往往看到的是對象的共性，而很少有個性。而且經常在使用繼承的時候會犯一個不是錯誤的錯誤，那就是子類否決父類的方法（我不知道怎么表達這個意思比較好，就是一種子類型的行為不符合父類的行為，也就是違反經典的里氏替換原則）。客戶端如何調用對象的個性呢？是向下轉型成我們的子類型還是使用轉換成行為接口呢？面向對象同樣也沒有解決方法，而設計模式之一的Visitor模式就很好解決了這個問題。這個時候客戶端作為一個Vistor的實現去訪問Vistable的子類，Vistable子類同樣調用客戶端Visitor，使得成為雙向調用來解決子類個性行為問題。

?

以上基本總結了由于抽象所帶來的問題（個性與共性問題，對象類型層次），以及設計模式如何解決這里問題的方案。所以我們不能為了面向對象而面向對象。實際上面向對象與面向結構的各自的問題也是導致Linus C與C++爭論的焦點問題的根源。

轉載于:https://www.cnblogs.com/zengyongjoy/archive/2010/06/30/1768732.html

總結

以上是生活随笔為你收集整理的设计模式是用来弥补面向对象编程缺陷的方法总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。