如今，面對對象方法幾乎成為了成功、先進、效率的代名詞。使用面對對象的方法設計和實現一個軟件幾乎成為了開發者們的默認選擇。但是，這種方法是否已經真正取得了成功了呢？真的達到了在他產生時候宣稱的優勢呢？很顯然對于這樣的問題大多數人是迷惑，不能作出肯定的回答。面對對象的方法在軟件分析和設計方面仍然遇到了困難，這些困難主要有這些表現：
1、抽象現實問題的方法不容易被開發者真正掌握。分解問題域中對象一般的思考方式有以下兩種，一種是抽象對象的性質，這種方法實際上就是對象繼承，第二種就是對象組合的方法。在經典的理論中認為對象的繼承是面對對象方法的實質，但是不符合大多數人的思維習慣。對于一個輪胎而言，人們更愿把它看成輪箍、外胎、內胎等等結構的組合體，而不是抽象成這樣的層次關系，橡膠-〉含有金屬的橡膠-含有金屬的圓形橡膠-〉輪胎。
2、分析到設計仍然不能平滑的過渡，在分析階段產生對象，往往有很多現實的名詞，這影響了設計者的思考，使他們不能關注對象在問題域中的關系，往往受到這些名詞其他含義影響。假定普通的企業管理系統中，分析作了人-〉公司職員-〉高級職員-〉經理的抽象，設計人員往往會被人、經理、高級職員這些名詞的影響，不能把這樣的現實對象很好的映射到程序結構中去，甚至會去定義人的姓名、年齡這些屬性，然而這些屬性在問題域中是不關心的，實際上在程序結構中人這個對象會和真正的人概念完全不一樣，之所以抽象這些對象實際上為了提取問題域中的靜態關系和動態關系，現實的名詞干擾了設計者。
3、面對對象方法產生的軟件沒有完全實現宣稱的軟件復用和簡化維護的目標。在沒有完全采用抽象對象性質的方法的時候，實際上完全采用也是很困難的，大多數人習慣于把復雜的事物分解成一組組合的對象，把簡單的事物進行抽象，在這種情況下產生的軟件結構是復雜的，對象組合之間必然充滿了復雜的消息，要進行重復使用和維護當然是不容易的。
4、缺乏評價一個面對對象設計的標準，一個設計，或者說怎樣做出一個能夠實現軟件復用、降低軟件復雜性的設計，沒有很好的理論支持。這本身就是由于對象抽象的靈活性造成的，不同的人對同樣的問題完全會有不同的抽象方法，面對對象的方法不限制人們抽象的方法，或者說根本沒有一套抽象的方法。我說的是抽象，和對象組合對應。缺乏標準，也必然造成軟件復用困難。
為了解決這些問題，很多人進行了回歸，我要說一些大逆不道的話了。第一個概念把繼承分解為接口繼承和實現繼承，認為對象實際上是實現和宣稱的方法集組成的，在現實的設計活動中，他們找到了復用的好辦法，因為他們把接口和實現分離，這樣在通過同樣的接口就可以操縱不同的對象，而不用關心背后對象的細節，這樣降低了對象之間的關聯程度。第二個概念，盡量使用對象組合而不是繼承，在把繼承分解以后，就會很自然的發現，純虛的基類實際上成為了對象的接口，而且為了復用的方便，幾乎完全不要實現繼承，因為復用是對象本身，而不是用它的基類，所以定義一個良好的組合成為了關鍵，而且繼承也會為這種復用帶來麻煩。我把這種解決方法稱為回歸，這是面對對象向結構化的回歸，或者說結構化方法的延伸。在對象進行復用的時候，一般不使用已經成型的對象，而是使用基類，復用的是基類已經實現的方法，當然這樣做，需要深刻理解原作者的意圖。一個只有一個純虛基類的對象和一個模塊有什么差別呢？這是模塊的復用。復用的只是接口，也就是一組定義，要實現支持同樣接口的不同對象，需要完全重新設計，實際上并沒有代碼復用。他把實現的復雜性推給了后面的設計者。如果僅僅把接口復用當成分析，在實現這個借口對象的時候仍然堅持實現繼承，也就是實現的時候仍然分層，那么這當然是可取的，但是我看不出需要接口繼承的意義。在這種方法下，設計者更傾向于進行問題的功能分解，舉個例子，設計企業的管理系統，設計者很可能在這種思考方式的主導下，劃分成財務部，人事部，業務部。這完全背離了面對對象方法的初衷。
大多數問題是復雜的，習慣總是明智的，把一個大的問題分解成小問題，在解決小問題的時候使用抽象的方法，可以說是一個很好的折衷，也是很有效率的。但是不能把整個問題都細化，或者說完全取消實現繼承，如果那樣我看不出這還是面對對象。我更愿意看到結構化方法和面對對象方法的融合，而不是盜用了面對對象的概念行結構化的做法。在對于評價分層抽象，或者說分層抽象指導原則、模式，幾乎沒有，這不能說是完整的。就像氣宗和劍宗構成了華山派一樣，獨孤九劍好像是絕種的劍宗武功，雖然難煉，但是殺了岳不群。