更好的设计？相同的对象，不同的可能的状态

Question

我有一个非常简单的应用程序，它由一个ASP.NET前端站点和一个WCF Windows服务执行繁重的后端逻辑。

用户有一个简单的页面，他选择一些参数并按下“提交”按钮。该页面调用WCF服务并将参数传递给它。该服务实例化了一个'Job'类的实例，将参数发送给构造函数，然后调用一个'Run（）'方法，该方法完成所有工作 - 将用户名，时间开始等...向第三方供应商发出请求，获取数据，将其放入数据库，执行其他业务逻辑，然后将该作业标记为已完成。

然后，用户有第二个简单页面，他现在可以搜索他的作业（按日期排序的可搜索组合框，显示与该作业相关的多个字段），然后在屏幕上显示与该作业相对应的数据 - （工作表中的大部分字段，例如开始时间，完成时间，状态等，在面板中显示为标签）以及我们从第三方供应商（在面板下方呈现为网格呈现）的实际数据。

现在我的问题 - 所以我有一个Job类，其中包含上面提到的所有字段，以及它的公共Run（）方法和构造函数。它有几个简单的私有函数，以及几个私有成员，这些成员是类IParser，IVendorConnection，IDataAccess的接口 - 完成上述所有实际工作的类......实际的Job类和Run（）方法并没有太多的作用实际的工作，几乎只是将工作委托给它的复合对象（使得可测试性尤其如此）。

现在，这个作业类有3种不同的可能用途/状态。它的主要用途是在Service内部使用Run（）函数来运行一个作业。它还有2个其他用途 - 充当上述面板的模型，并充当上述组合框的模型。工作类有3个公共构造函数，每个构造函数都为3个州中的一个设置。在所有情况下，每个不同的“州”只关心其他两个州不关心的某些成员 - 在某些情况下，某些成员在所有3个州都有使用。 '组合框状态'是最简单的 - 在这种情况下，我只需要3个只读字段。在“面板状态”中，我关心6个只读字段..在“工作”状态下，我基本上是在工作进程中创建这些字段值 - 而且它们都应该是私有的。

我只是寻找一个更干净的方式来做到这一点。如果我在状态A实例化一个Job类，我知道访问成员X将不起作用，或者调用函数Y失败。但是它仍然是可编译的代码。

我确信其他人以前都遇到过这个问题。我正在考虑将基本的Job类标记为MustInherit/abstract，然后有3个派生类，每个状态一个。将共享成员放在派生的基础和特定于状态的成员中，并在适当情况下在我的代码中使用派生类。这似乎足够简单，我的目的和解决我的问题。也许我也可能有某种JobFactory ......我想我只是在寻找其他人如何解决这个问题，也许我没有足够的思考......我有很多课程都是在状态机之前在我的爱好者游戏开发时间 - 但这是不同的，因为这些类别的实例可能会改变状态（例如，'敌人'级别的状态可能会从'attack_mode'更改为'waiting'）在我的情况中，没有变化的状态 - 一旦创建，一个工作必须保持其状态，从不试图以不同的方式行事。跟踪状态并抛出异常如果使用方法/成员而不处于给定状态看起来很脆弱和太多工作。基于你以前如何解决这个问题的任何建议？而我正在试图做什么矫枉过正？如果工作开始变得越来越不同的状态，我不会想 - 但也许如果它确实得到了许多不同的状态，那么我需要考虑将它分成不同的类别......只要找你的2美分。

Answer 1

你的想法是创建一个带有3个派生类的单个基类作业，听起来完全像我将要做的一样。创建JabFactory可能会进一步帮助设计。在某些情况下创建一个对象的部分对象未被使用或非法使用的做法可能是不好的做法。所以只用必要的部分创建派生类显然是更好的设计。这并不过分。