Частичный класс или «цепное наследование»

Question

С моей точки зрения, частичные классы немного нахмурены профессиональными разработчиками, но я столкнулся с проблемой;

Я выполнил реализацию элемента управления RichTextBox, который использует вызовы user32.dll для более быстрого редактирования больших текстов. Это приводит к довольно большому количеству кода. Затем я добавил контрольные возможности проверки орфографии, это было сделано в другом классе, наследующем элемент управления RichTextBox. Это также составляет немного кода.

Эти две функции довольно разные, но я бы хотел, чтобы они были объединены, чтобы я мог удалить один элемент управления в своей форме, который имеет как возможности быстрого редактирования, так и встроенную проверку орфографии. Я чувствую, что просто добавление формы кода одного класса к другому приведет к слишком большому кодовому файлу, тем более что есть две очень разные области функциональности, поэтому мне, похоже, нужен другой подход.

Теперь на мой вопрос; Чтобы объединить эти два класса, я должен заставить проверку орфографии RichTextBox наследовать от быстрого редактирования, который, в свою очередь, наследует RichTextBox? Или я должен сделать две частичные части одного класса и тем самым сделать их более «равными», так сказать?

Это больше вопрос принципов OO и упражнений с моей стороны, чем я, пытающихся изобрести колесо, я знаю, что есть много хороших инструментов для редактирования текста. Но для меня это просто хобби, и я просто хочу знать, как это решение будет решать профессионал.

Спасибо!

Answer 1

Я не совсем уверен, понимаю ли я, что вы пытаетесь сделать, но, как мне кажется, вы просто ищете Decorator design pattern. Если это не решит вашу проблему достаточно, и вы действительно думаете о создании классов из признаков, посмотрите на Policy based design, хотя я не уверен, насколько это возможно реализовать на C#. Существует также эта книга - Modern C++ design, которая является сторонником разработки на основе политики, однако в ней обсуждаются компромиссы для того, что вы называете частичными классами против (множественного) наследования. Проблема с цепным наследованием заключается в определении порядка, потому что этот порядок создает сильные зависимости, и если вы добавите SpellChecking в RichTextEdit, у вас возникнет проблема, если вы захотите использовать SpellChecking для, например, SearchBox, который может быть SimpleEdit, но было бы неплохо обеспечить проверку орфографии для пользователей ... Надеюсь, это поможет хотя бы немного.

Answer 2

Здесь есть аргумент для множественного наследования!

Вы можете определить интерфейс для функциональности (IFastEditTextBox и ISpellCheckingTextBox) и реализовать методы в каждом из них. Это будет больше OO, но есть потенциал для кода «копировать и вставлять».

Нет проблем с использованием частичных классов здесь. Единственная фундаментальная проблема с ними заключается в том, что они могут поощрять разработчика, который уже склоняется к процедурному подходу ко всему, что в одном классе.