C＃中派生类的可视化
我有一个基类（表示一个充满小球体的真实世界容器）和一些派生类。 这很好用。
我的问题是如何进行可视化。 我有一个UserControl可视化基类。 对每个派生类都有一个派生UserControl的最佳解决方案吗？ 或者只让一个人为所有人工作更好？
编辑：
显然我不够具体。 总有相同的基本外观：内部有很多圆圈的矩形。 类之间的区别在于容器的填充方式。 一种类型将种子放在中间并在树状结构中创建其他球体 – 在这种情况下，应绘制父母与子女之间的连接线。
一般来说，对于每种衍生类型，应该有类别的可视化与一些专业的一致外观。
这在很大程度上取决于显示器的相似程度。 如果派生类的显示与基类非常相似，那么您只需要一个UserControl来进行可视化。 OTOH，如果每个派生类需要显示唯一的东西，那么最好有一个单独的UserControl来可视化每个派生类。 如果没有关于课程的更具体的信息，我真的不能更具体。
编辑：从您的附加信息我会说你应该有一个基本显示类绘制commom矩形容器然后派生UserControls处理绘制每种特定类型的内容。
我怀疑只有你能肯定地回答这个问题。 给定子类的UI很可能是您想要的，但如果子类只是略有不同，您会发现在较少的用户控件中添加一些条件逻辑会更容易。 我认为这个问题没有一个正确答案。
很难从模糊的描述中说出来。 我们至少需要知道派生类之间的差异。
通常，在知识有限的情况下，我会为每个派生类使用一个派生的UserControl
如果派生类可视化没有彼此不同，那么，无论如何，请使用一个UserControl。 这里的要点是DRY。
解决问题的一种方法是按照MVVC的观点对其进行分解：
您将需要一个UserControl作为视图。
一个基础Painter，用于处理您的“带有圆圈的框”的绘画作为ViewModel。 Derived Painters实现了对象及其互连的不同定位逻辑。
如果对象的外观可能不同，那么它们本身应该作为ViewModel可能通过Adapter模式给予画家。
最后，你的圆圈，矩形和与它们相关的项目都是模型。
一般来说：
View（UserControl） – > ViewModel（Painter +派生的Painters +对象ViewModels） – >模型（圆形，矩形等）
我不完全理解你的问题域，但我认为你需要更多地解决这个问题。 将模型分解为零件并为每个零件写入视图，然后您可以将它们连接起来。
我会为你的球体写一个视图，一个你的球体之间的线条视图和一个包含所有东西的矩形的视图，然后你的每个模型将负责安排这些并创建相应的SphereModels和LineModel（以及你需要的任何其他东西）然后你的主视图只需要负责将这些放在盒子里。
记住总是喜欢构图和遗传！ 专注于将您的问题分解成更小的部分。
祝好运
我想我会使用一个基础Visualizer类，它有一些用于绘制圆和线的受保护方法，也许是绘图表面的一些属性（Canvas？），因此每个实现都可以计算基于测量的位置等。
基类实现了所有必要的接口方法/道具，使其成为可视化工具。
当您的可视化工具应该自己绘制时，在IDE调用的方法中使用策略模式…该方法实现可以清除canvas，设置画笔以及每个实现共有的其他内容 – 然后调用抽象方法实际将圆圈/框/行/等放在canvas上的基类。
这样，每个特定的实现只需要担心根据其规则集正确定位东西的逻辑 – 所有“canvas上的绘图内容”都保存在基类中。
HTH
编辑：纠正可能引起混淆的拼写错误，当我的意思是“可视化器”时，我使用了“控制”一词。
这听起来像是多种解决方案的情况。
一种方法是设置UserControl来调用基类中的虚方法，然后在派生类中重写它。 在派生类中，您可以最初调用基本实现来设置框架。
您还可以将其设置为在图层（容器图层，球体图层，线图层等）中渲染，并让子类渲染任何唯一图层，并确定顺序。 这可能很昂贵，但如果大部分图像保持不变，它可以平滑视觉效果。
另一种方法是使用委托而不是inheritance，但这往往会变得混乱。 由于性能损失，这通常不是一个好主意。 但是，它确实具有运行时灵活性的优势。 根据您的其余代码，您可以使用此模型在中途切换增长方式。 如果你没有看到自己利用这种灵活性，我建议你使用不同的模型。
无论您使用何种方法，我都建议基类提供常用的绘图例程以确保一致性。 大多数子类都应该使用基类中的例程，但不一定都是。 这通常会导致更易于管理的代码（除非您最终获得10000行文件），更少的错误和更少的工作量。
这对我来说就像装饰者模式一样：