ac＃類應該生成自身的實例嗎？

Question

我有一個定義CallRate類型的類。 我需要通過從文件中讀取數據來添加創建類的多個實例的功能。

我在類CallRate中添加了一個靜態方法，該方法返回List<CallRate> 。 類可以通過調用其自己的構造函數之一來生成自身的新實例嗎？ 它有效，我只是想知道這是否是正確的選擇。

List<CallRates> cr = CallRates.ProcessCallsFile(file);

Answer 1

從靜態方法中獲得自己的對象是完全可以的。

例如

一個點網庫的功能與您相同，

XmlReadrer reader = XmlReader.Create(filepathString);

Answer 2

當然可以，在某些情況下甚至可以鼓勵。 有幾種設計模式可以處理對象創建 ，其中一些可以滿足您的描述。

Answer 3

當我需要檢查參數的有效性時，我經常使用這種模式。 強烈建議不要從構造函數中引發異常。 從工廠方法來看還不錯，或者您可以選擇返回null。

Answer 4

對我來說似乎很好。 在其他語言中，您可能會編寫一個函數，但是在C＃這樣的語言中，靜態方法將扮演該角色。

Answer 5

沒關系。 您剛剛創建的內容就像一個簡單的工廠方法。 您有一個靜態方法來創建類型的有效實例。 實際上，您的方法甚至不必是靜態的，並且您仍然具有有效的代碼。 有一個設計模式（原型），可以從現有對象創建一個新的有效對象。 有關詳細信息，請參見http://www.dofactory.com/Patterns/PatternPrototype.aspx 。

Answer 6

當然，對於簡單的解析（或類似）場景-實際上，我更喜歡 工廠方法作為類的一部分。 是的-它確實打破了SRP ，但是滿足了KISS的要求 -所以我稱之為凈贏。 對於較大的應用程序或更復雜的解析例程，將其作為外部工廠類更有意義。

對於您的特殊情況，我可能更喜歡采用IEnumerable <string>而不是文件名的方法-仍然可以為您提供解析邏輯，但允許簡單的單元測試和“重用”。 調用者可以很容易地將文件包裝到IEnumerable中。

Answer 7

工廠方法通常是一個好的設計。 當我用C＃編寫它們時，我將它們稱為“新建”，因此：

new MyClass()

變成

MyClass.New()

瑣碎地是這樣實現的：

class MyClass
{
    public static MyClass New()
    {
        return new MyClass();
    }
}

通常，當存在關於是否要實際創建類或僅返回null或是否返回MyClass或派生自其的某些其他條件時，我會這樣做。

Answer 8

有時我會使用公共靜態方法來替代構造函數重載。

尤其是在僅依靠參數類型來指示打算使用哪種對象構造的情況下，這種情況尤為明顯。

Answer 9

我喜歡上面提到的很多次讓靜態方法返回實例。

@Paul：別忘了在上面的評論中打勾，您會發現這是最佳答案。

Answer 10

就像指出“通過調用自己的構造函數之一來生成自身的新實例”

它不是來自構造函數，而是來自靜態方法。

Answer 11

我通常在需要即時實現類時使用它。 例如

    public class Car
    {
        public static Car RedExpensiveCar = new Car("Red", 250000);

        public Car()
        {

        }

        public Car(string color, int price)
        {
            Color = color;
            Price = price;
        }

        public string Color { get; set; }
        public int Price { get; set; }
    }

這樣，我就無需在代碼中記住或編寫構造函數參數。

Car car = Car.RedExpensiveCar;

Answer 12

這樣做是完全可以接受的。 當我這樣做時，我通常將類的實際構造函數設為私有，這樣很明顯構造實例的唯一方法是通過靜態方法。

這在“構造”可能不總是返回新實例的情況下非常有用。 例如，您可能想要返回以前緩存的對象。