2010-04-30 71 views
4

從我的理解中,部分課程有點被專業開發人員所詬病,但我已經過了一些問題;部分課程或「鏈式繼承」

我已經制作了一個RichTextBox控件的實現,該控件使用user32.dll調用來更快地編輯大型文本。這導致了很多代碼。然後我向控件添加了拼寫檢查功能,這是在另一個繼承RichTextBox控件的類中完成的。這也構成了一些代碼。

這兩個功能是非常獨立的,但我希望它們合併,以便我可以在我的窗體上放置一個控件,該窗體既具有快速編輯功能,又具有內置的拼寫檢查功能。我覺得簡單地將代碼添加到一個類中到另一個會導致一個太大的代碼文件,特別是因爲有兩個非常獨特的功能區域,所以我似乎需要另一種方法。

現在我的問題;爲了合併這兩個類,我應該讓拼寫檢查RichTextBox從快速編輯繼承,繼而繼承RichTextBox?或者,我應該讓這兩個班的部分班級成爲一個班級,從而讓他們更「平等」這麼說?

這是更多的OO原則和運動的問題,比我試圖重新發明輪子,我知道有很多很好的文本編輯控件。但這只是我的一個愛好,我只想知道這種解決方案是如何由專業人員管理的。

謝謝!

回答

2

我不完全相信,如果我明白你正在嘗試做什麼,但就我看來,你只是在尋找Decorator design pattern。如果這不足以解決您的問題,並且您真的在考慮編寫特性類,請參閱Policy based design,儘管我不太確定在C#中可以實現多少。 還有一本書 - Modern C++ design它是基於策略的設計的支持者,但它討論了所謂的部分類與(多)繼承之間的權衡。鏈式繼承的問題在於決定順序,因爲該順序會產生強烈的依賴關係,並且如果將拼寫檢查添加到RichTextEdit中,則一旦您想對例如「拼寫檢查」使用拼寫檢查,就會遇到問題。 SearchBox,它可能是SimpleEdit,但爲用戶提供拼寫檢查會很好......我希望這至少有一點幫助。

1

這裏有一個多重繼承的論點!

您可以爲功能定義接口(IFastEditTextBox和ISpellCheckingTextBox)並在每個接口中實現方法。這將是更多的面向對象,但有可能「複製和粘貼」代碼。

在這裏使用部分類沒有任何問題。與他們唯一的根本問題是他們可能會鼓勵一個開發人員已經傾向於採用程序方法將所有代碼編入一個類。

+0

我對接口的使用(和理解)非常有限,但是這種方法基本上不會強制我重複SpellCheckingTextBox中的FastEditTextBox代碼,反之亦然? – 2010-04-30 08:41:13

+1

我想你會考慮到常見的調用,並在拼寫檢查器類和快速編輯類上實現IExtensibleRichTextBox。正如Gabriel所說,這將允許你實現裝飾者模式。您可以根據需要定義快速,拼寫檢查或快速拼寫檢查。有關裝飾者模式的完美概述,請參閱O'reilly書籍中的免費章節,首先設計模式:http://oreilly.com/catalog/hfdesignpat/chapter/ch03.pdf – 2010-04-30 11:19:50