Базові класи як фабрики?

Я писав якийсь код у вихідні, і я виявив, що хочу написати фабрику як статичний метод у базовому класі.

Моє запитання полягає в тому, щоб просто знати, чи це підхід # idomatic?

Моє відчуття, що це може бути не тим, що базовий клас має знання похідного класу.

Однак, я не впевнений у більш простому способі отримати той же результат. Цілий інший заводський клас здається мені (принаймні, як) непотрібною складністю (?)

Щось на зразок:

class Animal
{
  public static Animal CreateAnimal(string name)
  {
     switch(name)
     {
        case "Shark":
          return new SeaAnimal();
          break;
        case "Dog":
          return new LandAnimal();
          break;
        default:
          throw new Exception("unknown animal");
     }
  }
}
class LandAnimal : Animal
{
}

class SeaAnimal : Animal
{
}

Що ж, перевага окремого фабричного класу полягає в тому, що його можна глузувати в одиничних тестах.

Але якщо ви цього не збираєтеся робити або робити це поліморфним будь-яким іншим способом, то статичний заводський метод для самого класу в порядку.

Ви можете використовувати Generics, щоб уникнути оператора перемикання та від'єднати наступні реалізації від базового класу.

 public static T CreateAnimal<T>() where T: new, Animal
 {
    return new T();
 }

Використання:

LandAnimal rabbit = Animal.CreateAnimal();  //Type inference should should just figure out the T by the return indicated.

або

 var rabbit = Animal.CreateAnimal<LandAnimal>(); 

Якщо взяти до кінця, фабрика також може бути загальною.

interface IFactory<K, T> where K : IComparable
{
    T Create(K key);
}

Тоді можна створити будь-який тип фабричних об'єктів, який, у свою чергу, міг би створити будь-який тип об’єкта. Я не впевнений, що це простіше, це, звичайно, більш загальне.

Я не бачу нічого поганого в заяві перемикача для невеликої фабричної реалізації. Після того, як ви потрапили у велику кількість об'єктів чи можливих ієрархій різних класів, я думаю, що більш загальний підхід краще підходить.

Погана ідея. По-перше, це порушує принцип відкрито-закритого типу. З будь-якою новою твариною вам знову доведеться возитися з базовим класом, і ви потенційно можете його зламати. Залежності пішли б неправильним шляхом.

Якщо вам потрібно створити тварин із конфігурації, така конструкція буде такою ж нормальною, хоча використання відображення для отримання типу, що відповідає імені, та інстанціювання його за допомогою отриманої інформації про тип було б кращим варіантом.

Але вам все одно слід створити виділений заводський клас, від'єднавшись від ієрархії класів тварин, і повернути інтерфейс IAnimal, а не базовий тип. Тоді це стане в нагоді, ви б досягли певної розв’язки.

Це питання для мене своєчасне - я писав майже саме такий код вчора. Просто замініть "Animal" на те, що є релевантним для мого проекту, хоча я дотримуватись "Animal" заради обговорення тут. Замість заяви «switch» у мене був дещо складніший ряд висловлювань «if», що передбачав більше, ніж просто порівняння однієї змінної з певними фіксованими значеннями. Але це деталь. Статичний заводський метод видався акуратним способом проектування речей, оскільки конструкція виникла з рефакторингу раніше швидких і брудних помилок коду.

Я відхилив цю конструкцію на підставі того, що базовий клас має знання похідного класу. Якщо класи LandAnimal та SeaAnimal невеликі, акуратні та прості, вони можуть бути в одному вихідному файлі. Але у мене є великі безладні методи для читання текстових файлів, які не відповідають жодному офіційно визначеному стандарту - я хочу, щоб мій клас LandAnimal був у своєму власному вихідному файлі.

Це призводить до кругової залежності файлів - LandAnimal походить від Animal, але Animal вже повинен знати, що існують LandAnimal, SeaAnimal та п’ятнадцять інших класів. Я витягнув заводський метод, вклав його у свій власний файл (у моєму головному додатку, а не в моїй бібліотеці тварин). Статичний заводський метод здався милим і розумним, але я зрозумів, що він насправді не вирішує жодної проблеми дизайну.

Я поняття не маю, як це стосується ідіоматичного C #, оскільки я дуже перемикаю мови, я зазвичай ігнорую ідіоми та умовності, властиві мовам та стекам розробників поза моєю звичайною роботою. Якщо щось моє C # може виглядати "пітонічним", якщо це має сенс. Я прагну загальної ясності.

Крім того, я не знаю, чи не було б переваги використовувати статичний заводський метод у випадку невеликих, простих класів, які навряд чи будуть розширені в майбутній роботі - мати це все в одному вихідному файлі може бути непогано в деяких випадках.