軟件測試關于面向對象的一些思考[2] 軟件測試工具
關鍵字：面向對象 思考
比如，我實現一個 GUI 系統(或是一個 3d 世界)。需要實現一個功能——判斷鼠標點選到了什么物件。這里，每個物件提供了一個方法，可以判斷當前鼠標的位置有沒有捕獲(點到)它。
這時最簡單的時候方法是：把所有可以被點選的物件都放在一個容器中，每次遍歷這個容器，查看是哪一個物件捕獲了鼠標。
我們并不需要可被點選的物件都是同類，只需要要求從容器中可以以統一方法訪問每個元素的是否捕獲住鼠標的這個判定方法。
也就是說，把對象置入容器時，只需要讓置入的東西有這一個判定方法即可。了解 COM 的同學應該明白我要說什么了。對，這就是 QueryInterface 的用途。com 的 query interface 就是說，從一個對象里取到一個特定可以做某件事情的接口。通常接下來的代碼會把它放在一個容器里，方便別處的代碼可以干這些事情。
面向對象的本質就是讓對象有多態性，把不同對象以同一特性來歸組，統一處理。至于所謂繼承、虛表、等等概念，只是實現的細節。
說到這里，再說一下 COM 。COM 允許 接口繼承 ，但不允許接口多繼承。這一點是從二進制一致性上來考慮的。
為什么沒提 實現繼承 的事情?因為實現繼承不屬于面向對象的必要因素。而且，現在來看，實現繼承對軟件質量來說，是有負面影響的。因為如果你改寫基類的虛方法，就意味著有可能破壞基類的行為(繼承角度看，基類對象是你這個對象的一部分)。往往基類的實現早于派生類，并不能了解到派生類的需求變化。這樣，在不了解基類設計的前提下，冒然的實現繼承都是有風險的。這不利于軟件的模塊化分離和組件復用。
但是接口繼承又有什么意義呢?以我愚見，絕大多數情況下，同樣對設計沒有意義。但具體到 COM 設計本身，讓每個接口都繼承于 IUnknown 卻是有意義的。這個意義來至于基礎設施的缺乏。我指的是 GC 。在沒有 GC 的環境中，AddRef 和 Release 相當于讓每個對象自己來實現 RC (引用計數)的自動化管理。對于非虛擬機的原生代碼，考慮到 COM 不依賴具體語言，這幾乎是唯一的手段。另外 COM 還支持 apartment 的概念，甚至允許 COM 對象處于不同的機器間，這也使得 GC 實現困難。
QueryInterface 存在于每個 COM 接口中卻有那么一點格格不入。它之所以存在，是因為 COM 接口指針承擔了雙重責任，既指出了一個抽象概念，又引用了對象的實體。但從一個具體算法來看，它只需要對一組相同的抽象概念做操作即可。但它做完操作后，很可能(但不是必須)需要把對象放入另一個不同的集合中，供其它算法操作。這個時候，就需要 QueryInterface 將其轉換為另外一個接口。
但是，從概念上講，讓兩個不相關的接口相互轉換是不合邏輯的。本質上，其實在不相關的接口間轉換做的事情等價于：從一個接口中取得對對象的引用，然后調用這個對象的方法，取到新的接口。
如果去掉了 AddRef Release (依賴 GC )以及 QueryInterface (只在需要時增加一個接口獲得對象的引用)，IUnknown 就什么都不剩了。那么接口繼承也完全不必存在。
回頭再來看程序語言。
C++ 提供了對面向對象的支持，但 C++ 所用的方法(虛表、繼承、多重繼承、虛繼承、等等)只是一種在 C 已有的模型上，追加的一種高效的實現方式而已。它不一定是最高效的方式(雖然很少能做到更高效)，也不是最靈活的方式(可以考察 Ruby )。我想，只用 C++ 寫程序的人最容易犯的錯誤就是認為 C++ 對面向對象的支持的實現本身就是面向對象的本質。如果真的理解了面向對象，在特定需求下可以做出特定的結構來實現它。語言就已經是次要的東西了。
了解你的需求，區分我需要什么和我可以做到什么，對于設計是很重要的。好的設計在于減無可減。
你需要面向對象嗎?你需要 GC 嗎?你需要所有的類都有一個共同的基類嗎?你需要接口可以繼承嗎?你為什么需要這些?
文章來源于領測軟件測試網 http://www.kjueaiud.com/
