C#依赖于另一个枚举的枚举[或者这可能与设计更相关]

我可能走错了方向，所以让我试着整理一下我的想法（希望你们能给我一些建议）：

想象一个枚举：

public enum ReportType
{
   Performance,
   Trending,
   Statistical
}

此枚举也将是窗体构造函数的属性或参数。ReportType的值将决定以下事项：

a) the text displayed at the top of the form
b) Which controls are visible
c) the text for a combobox <---!!!! this is where the 2nd enum comes in

如果是趋势，我希望：

public enum PerformanceGraph
{
    Bar,
    Line,
    Pie,
    Area
}

public enum TrendingGraph
{
    Bar,
    Line
}

此表单只是收集用户输入。我的意思是，我不想为了一个简单的形式而进入一些复杂的继承结构。当我能快速做以下事情时，似乎需要付出很多努力（我可能错了）：

（想象一下这个构造函数）

当你想用GraphCombo做点什么的时候，它开始变得毛茸茸的，因为现在你需要知道它是哪一种报表类型，用于铸造目的

另外，回到我的构造函数，假设我想给它发送一个图形值，这样我们就可以设置GraphCombo的SelectedIndex（这可能是用户上次选择的值，而不是设置某种类型的默认值）。嗯

 public ReportInputForm(ReportType RptType, ???WhichGraphEnum???)
 {
 }

我的意思是，现在有三个graph enum，因为有三个ReportType。另外，想象一下再添加几个ReportType

我想我可以使用int/long：

 public ReportInputForm(ReportType RptType, int lastGraphType)
 {
 }

但我想我是想在这里做Enum先生，进行编译时检查。换句话说，如果我可以使用某种类型的枚举，我可以检测到错误（如下所示）：

与之相反：

// Is 4 even a valid graph type for the trending report?  Answer: No
ReportInputForm foo = new ReportInputForm(ReportType.Trending, 4);

我已经说得够多了。也许这更像是一个设计问题，而不是与枚举相关的问题。我只是想了解一下如何处理这个问题。谢谢

################################################################################## ################################################################################## ########################编辑从这里开始######################################## ################################################################################## ################################################################################## 这是对使用泛型的回应（如果我有点慢，我很抱歉；感谢Daniel的回复）：

这里有一个建议：

ReportInputForm<TrendingReport> = new ReportInputForm<TrendingReport>(GraphType.Area);

如果我使用的是TrendingReport，我希望我的GraphType枚举为：

public enum PerformanceGraph
{
    Bar,
    Line,
    Pie,
    Area
}

public enum TrendingGraph
{
    Bar,
    Line
}

换句话说，这个枚举依赖于类（或者正如我最初的问题所述，依赖于第一个枚举）

我的意思是，我想我可以在抽象类中放置一个包含所有图形类型的枚举：

public abstract class ReportType
{
    public enum GraphType
    {
        Bar,
        Line,
        Pie,
        Area
    }

    public abstract string GetTitle();
}

但是，这违背了我最初问题的目的。因为这现在是合法的（假设我修改了Form1的构造函数）：

form1f=newform1（ReportType.GraphType.Pie）；

记住，TrendingReport应该只有条和线。我正在尝试编译时检查这个。我肯定也遗漏了一些东西（关于泛型）。

泛型形式

  ReportInputForm<T>

ReportInputForm

如果表单的类型取决于枚举的值，我会将枚举转换为类型本身。然后将表单类设置为泛型

例如：

ReportInputForm<TrendingReport> = new ReportInputForm<TrendingReport>(GraphType.Area);

ReportInputForm=新的ReportInputForm（GraphType.Area）；

甚至：

ReportInputForm<AreaGraph> = new TrendingReportForm<AreaGraph>();

ReportInputForm=newtrendingreportform（）；

假设

TrendingReportForm

是

ReportInputForm

的子类

---

任何时候，如果某个类的行为根据某个枚举值发生变化，则应寻找机会将变化的行为重构为一个可委托给子类的单独方法。

这听起来是一个使用继承的非常合理的地方，使用基类

ReportInputForm

和子类

PerformanceReportInputForm

、

TrendingReportInputForm

和

StatisticalReportInputForm

。它看起来并不特别复杂，并且在维护编译时类型检查的同时，它巧妙地避免了任何switch/case语句或长if链。或者，您可以根据策略模式来实现它，这增加了一些脚手架和开销，但允许您动态更改报告类型。

对我来说，我觉得这更像是一个设计问题，不是很糟糕，只是需要一些调整以实现可重用性，并减少混乱的编码。您实际上不需要“详细的继承层次结构“为了这个。单个抽象报表基类和允许类型的每个子类枚举将为您提供所需的一切，而无需所有复杂的ifs/切换。我认为最好将通用功能移动到表单使用的单独类。让表单本身成为泛型会使IDE和设计器的工作变得棘手。@Snarfblam：不过，想必，使用可视化设计器编辑的唯一表单是基类。我可能会将其反转，并生成一个由Form类参数化的泛型类（而不是

Form

的子类），如

TrendingReport

——根据应用程序的不同，这可能是最好的解决方案。我可能有点慢。。。但我不知道如何使用泛型来解决我的原始问题。我会编辑我的原始问题，这样我就可以提供代码了。我用了一些接近这个的东西。一个抽象基类（ReportType），有四个继承自它的类（基本上这些类有一堆getter）。我在表单外部构造所需的继承类型，然后将其传递给表单，并在需要特定于该类型的内容时使用该ReportType（消除一些if/else语句）。

public abstract class ReportType
{
    public enum GraphType
    {
        Bar,
        Line,
        Pie,
        Area
    }

    public abstract string GetTitle();
}

Form1<TrendingReport> f = new Form1<TrendingReport>(ReportType.GraphType.Pie);

  ReportInputForm<T>

ReportInputForm<TrendingReport> = new ReportInputForm<TrendingReport>(GraphType.Area);

ReportInputForm<AreaGraph> = new TrendingReportForm<AreaGraph>();