Визуализация производных классов в C#

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

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

РЕДАКТИРОВАТЬ: Из вашей дополнительной информации я бы сказал, что у вас должен быть базовый класс отображения, который рисует прямоугольный контейнер commom, а затем производные UserControls, которые обрабатывают рисование содержимого каждого конкретного типа.

Если визуализация производных классов не отличается друг от друга, то в любом случае используйте один UserControl. Главное здесь - СУХОЙ.

Один из подходов к проблеме заключается в ее декомпозиции в соответствии с перспективой MVVC:

Вам понадобится один UserControl в качестве представления.

Один базовый Painter, который обрабатывает рисование вашего «квадрата с кругами в нем» как ViewModel. Derived Painters реализуют различную логику позиционирования объектов и их взаимосвязей.

Если внешний вид ваших объектов может отличаться, то они сами должны быть переданы художнику как ViewModel, возможно, через шаблон адаптера.

И, наконец, ваши круги, прямоугольники и связанные с ними предметы - это Модель.

Вообще говоря:

Просмотр (UserControl) -> ViewModel (Painter + производные Painters + объект ViewModels) -> Модель (круг, прямоугольник и т. Д.)

Трудно сказать по расплывчатому описанию. Нам действительно нужно знать, по крайней мере, в чем различия между производными классами.

Обычно, обладая ограниченными знаниями, я бы выбрал один производный UserControl для каждого производного класса

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

Я бы написал представление для ваших сфер, представление для линий между вашими сферами и представление для прямоугольника, содержащего все, тогда каждая из ваших моделей будет отвечать за их расположение и создание соответствующих SphereModels и LineModels (и всего, что вы need), тогда ваше основное представление просто должно отвечать за их размещение в коробке.

Помните, всегда предпочитайте композицию наследованию! Сосредоточьтесь на том, чтобы разбить проблему на более мелкие части.

удачи

Думаю, я бы выбрал базовый класс визуализатора, у которого были некоторые защищенные методы для рисования кругов и линий и, возможно, какое-то свойство для поверхности рисования (Canvas?), чтобы каждая реализация могла вычислять позиции на основе измерений и т. д.

Базовый класс реализует все необходимые методы / свойства интерфейса, чтобы сделать это визуализатор.

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

Таким образом, каждая конкретная реализация должна беспокоиться только о логике для правильного позиционирования материала в соответствии с ее набором правил - все «рисование на холсте» сохраняется в базовом классе.

HTH

EDIT: исправлена ​​опечатка, которая могла вызвать путаницу, где я использовал слово «контроль», когда имел в виду «визуализатор».

Этот звук для меня похож на шаблон декоратора:

http://en.wikipedia.org/wiki/Decorator_pattern

Это похоже на ситуацию с несколькими решениями.

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

Можно также настроить его на послойное отображение (слой-контейнер, слой-сфера, слой-линия и т.д.), а дочерний класс будет отображать все уникальные слои и определять их порядок. Это может быть дорого, но может сгладить визуальный эффект, если большая часть изображения остается неизменной.

Другой вариант - использовать делегаты в противовес наследованию, но это может привести к беспорядку. Как правило, это не очень хорошая идея из-за потерь производительности. Однако у него есть преимущество - гибкость во время выполнения. В зависимости от остальной части вашего кода, вы, возможно, сможете переключить стиль роста на середине пути с помощью этой модели. Если вы не планируете использовать эту гибкость, я бы рекомендовал вам использовать другую модель.

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