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

Question

У меня есть базовый класс (представляющий контейнер реального мира, заполненный маленькими сферами) и некоторые производные классы.Это прекрасно работает.
Моя проблема в том, как сделать их визуализацию.У меня есть UserControl, визуализирующий базовый класс.Является ли лучшим решением иметь производный UserControl для каждого из производных классов?Или лучше, чтобы на всех них работал только один?
Редактировать:
Очевидно, я не был достаточно конкретен.Основной вид всегда один и тот же: прямоугольник с множеством кружков внутри.Разница между классами заключается в том, как заполнен контейнер.Один тип помещает семя в середину и создает другие сферы в древовидной структуре - в этом случае следует проводить соединительные линии между родителями и их детьми.
Как правило, визуализация классов должна быть согласованной с несколькимиособенности для каждого производного типа.

Answer 1

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

EDIT: Из вашей дополнительной информации я бы сказал, что у вас должен быть базовый класс отображения, который рисует прямоугольный контейнер commom, а затем производные UserControls, которые обрабатывают рисование содержимого каждого конкретного типа.

Answer 2

Это звучит для меня как шаблон декоратора:

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

НТН

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

Answer 5

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

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

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

удачи

Answer 6

Одним из подходов к проблеме будет разложение ее по перспективе MVVC:

Вам понадобится один пользовательский элемент управления для просмотра.

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

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

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

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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