更好的設計？相同的對象，不同的可能的狀態

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可能會進一步幫助設計。在某些情況下創建一個對象的部分對象未被使用或非法使用的做法可能是不好的做法。所以只用必要的部分創建派生類顯然是更好的設計。這並不過分。