這是靜態類實現的正確體系結構嗎？

Question

我有一個靜態類，其中包含各種實用程序，為簡化起見，我添加了“客戶”和“訂單”：

public static MyUtilityClass()
{
   public static readonly AnExpensiveObject ExpensiveObject = null; 
   public static Customers Customers;
   public static Orders Orders;

     static MyUtilityClass()
     {
        if (ExpensiveObject == null)
        { 
            ExpensiveObject = //Expensive operation
        }
     }   
}

在上面的代碼中，AnExpesiveObject ExpensiveObject是“客戶和訂單”將使用的實用程序類的屬性。

我已經這樣聲明的客戶：

public class Customers
{
     public void SomeMethod()
     {
         var x = MyUtilityClass.ExpensiveObject; 
     }
}

我要嘗試的理論：

1. 創建一個具有子類作為屬性的靜態類，這樣我就可以編寫簡潔的代碼，例如：

   Utilities.Customers.GetCustomerById(50);

2. 讓這些實用程序類能夠訪問父類中的屬性，在這里，由於父類是靜態的，因此我將直接訪問其屬性，而無需任何繼承模型。 這是正確的方法嗎？

3. 最后，Customers（該類）的編碼是非靜態的，所以我必須在MyUtilityClass（）中創建它的新實例，還是因為它是MyUtilityClass的靜態屬性，所以不需要嗎？

Answer 1

冒着回答過於籠統的問題的風險，我將給出我認為是正確的簡短答案：不，這不是做您想做的事情的正確方法。

不幸的是，當您詢問繼承時，您的代碼示例中沒有任何內容顯示對繼承的任何使用。 因此，不可能理解您的意思。

然而，更麻煩的是您的第三點提出的問題：

3. 最后，Customers（該類）的編碼是非靜態的，所以我必須在MyUtilityClass（）中創建它的新實例，還是因為它是MyUtilityClass的靜態屬性，所以不需要嗎？

您必須要問這個問題的事實強烈表明，設計存在一些根本性的缺陷。

特別是， 我會問你的問題是：什么類型的類是Customers ？ 也就是說，程序擁有多個實例是否有意義？

這個問題很重要，在兩個可能的答案中，都引出了后續問題，都指出擬議的設計是錯誤的：

1. 可能的答案1：“不，一次只能有一個Customers對象”。 在那種情況下，將類實現為單例更有意義，這意味着訪問器應該是例如Customers類本身的Instance屬性，而不是單獨的“ utility”類中的某些屬性。
2. 可能的答案2：“是的，在執行該程序期間可以有多個Customers對象實例”。 在那種情況下，會提出一個問題， 即哪個實例在您的“實用程序”類中成為“特殊”實例，為什么？ 此外，是否可能有不止一個實例具有該特殊地位？ 為什么或者為什么不？

希望這是上面第一個正確的答案，在這種情況下，路徑很明確：使用單例模式，而不要使用這種包羅萬象的“實用程序”類。

如果上面的第二個答案是正確的，那么我可以肯定地說您的設計不正確。 不幸的是，說什么的設計是正確的就困難得多，而且會從您需要更詳細，使得這個問題本身過於廣泛用於StackOverflow的。

Answer 2

它可以按我預期的方式工作，並且易於重用，因此我將回答這個問題。