tags:

views:

97

answers:

2

Hi

From my understanding partial classes are a bit frowned upon by professional developers, but I've come over a bit of an issue;

I have made an implementation of the RichTextBox control that uses user32.dll calls for faster editing of large texts. That results in quite a bit of code. Then I added spellchecking capabilities to the control, this was made in another class inheriting RichTextBox control as well. That also makes up a bit of code.

These two functionalities are quite separate but I would like them to be merged so that I can drop one control on my form that has both fast editing capabilities and spellchecking built in. I feel that simply adding the code form one class to the other would result in a too large code file, especially since there are two very distinct areas of functionality, so I seem to need another approach.

Now to my question; To merge these two classes should I make the spellchecking RichTextBox inherit from the fast edit one, that in turn inherits RichTextBox? Or should I make the two classes partials of a single class and thus making them more “equal” so to speak?

This is more of a question of OO principles and exercise on my part than me trying to reinvent the wheel, I know there are plenty of good text editing controls out there. But this is just a hobby for me and I just want to know how this kind of solution would be managed by a professional.

Thanks!

+1  A: 

There's an argument for multiple inheritance here!

You could define an interface for the functionality (IFastEditTextBox and ISpellCheckingTextBox) and implement the methods in each one. This would be more OO but there's the potential for "copy-and-paste" code.

There isn't any problem with using partial classes here. The only fundamental issue with them is they might encourage a developer who already leans towards a procedural approach to code everything into one class.

David Neale
My use (and understanding) of interfaces is very limited, but wouldn't that approach basically force me to repeat the FastEditTextBox code in the SpellCheckingTextBox an vice versa?
Charlie boy
I think you would factor out the common calls and implement an IExtensibleRichTextBox on both the spell checker class and the fast edit class. As Gabriel suggests, this would allow you to implement the decorator pattern. You could then define fast, spell checked or fast spell checked, depending on your needs. For a great overview of the decorator pattern, check out the free chapter from the O'reilly book, Head First Design patterns: http://oreilly.com/catalog/hfdesignpat/chapter/ch03.pdf
Mark Booth
+2  A: 

I am not entirely sure if I understand what you are trying to do, but as it seems to me, you are just looking for the Decorator design pattern. If this does not solve your problem enough and you are really thinking about composing classes from traits, look at Policy based design, although I am not so sure how much of that is possible to implement in C#. There is also that book - Modern C++ design which is a proponent of Policy based design, however it discusses the trade-offs for what you call partial classes versus (multiple) inheritance. The problem with chained inheritance is in deciding the order, because that order cretes strong dependencies and if you add SpellChecking to RichTextEdit, you would encounter a problem once you want to use SpellChecking for e.g. SearchBox, which might be SimpleEdit, but it would be nice to provide spellchecking for users... I hope this helps at least a bit.

Gabriel Ščerbák