Базовый класс для управления заводскими классами

Question

У меня есть StaffFactory для получения объектов персонала различными способами, но у меня также есть некоторые методы настройки, чтобы определить, какой источник данных использовать.

class StaffFactory 
{ 
    private const string DefaultDbSourceName = "Production"; 
    private string dbSourceName; 
    #region Factory Management 
    private static Dictionary<string, StaffFactory> staffFactories = new Dictionary<string,StaffFactory>(); 
    public static StaffFactory GetInstance() 
    { 
     return GetInstance(DefaultDbSourceName); 
    } 
    public static StaffFactory GetInstance(string dbSourceName) 
    { 
     if (!staffFactories.ContainsKey(dbSourceName)) 
     { 
      staffFactories.Add(dbSourceName, new StaffFactory(dbSourceName)); 
     } 
     return staffFactories[dbSourceName]; 
    } 
    private StaffFactory(string dbSourceName) 
    { 
     this.dbSourceName = dbSourceName; 
    } 
    #endregion Factory Management 
    #region Factory Methods 
    public Staff ById(int id) { ... } 
    public IList<Staff> ByName(string name) { ... } 
    ... 
    #endregion Factory Methods 
} 

Как я иду, чтобы создать свой следующий завод, я понимаю, все это логика управления будет оставаться такими же независимо от того, какого типа завода для. Поэтому я думаю, что я создаю базовый класс Factory или Factory, в котором находится эта логика, а затем объявляю выше с помощью class StaffFactory : Factory<Staff> { ... } или что-то в этом роде, но я рисую полные пробелы о том, как бы я это сделал. Внедрить ли это с использованием дженериков и т. Д.

Может ли кто-нибудь указать мне правильное направление?

Answer 1

Перед тем, как ввести новый уровень абстракции, убедитесь, что преимущества перевешивают затраты. В вашем случае, те будут включать:

Стоимость для разработки и реализации абстракции

StaffFactory гораздо проще разрабатывать, внедрять и тестировать, чем родового Factory <T> класса.

Стоимость понять завод < Т > абстракцию

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

Стоимость внесения изменений в будущем

Допустим, что у вас есть завод <Staff> и завод < Продукт >, и в будущем вы обнаружите, что вы хотите другую политику кэширования для двух. Возможно, завод < Продукт > должен отбрасывать кешированный объект, если размер кеша превышает некоторый порог.

Вы собираетесь обобщить завод < > класс для поддержки различных режимов? Это можно сделать, но гораздо сложнее, чем просто модифицировать классы StaffFactory и ProductFactory самостоятельно.

Резюме

Таким образом, не вводить абстракцию только ради него. И, безусловно, не обобщайте StaffFactory в общий завод <T>, если Factory < Персонал > будет единственным генерирующим экземпляром, который у вас будет.

От вашего кода выше, кажется, что ваш завод <T> класс будет в основном в словаре < string, T >. Если это так, то введение дополнительного родового класса Factory не принесет вам большой пользы и добавляет лишний уровень абстракции.

Answer 2

Поскольку я понимаю, что вы собираетесь реализовать, это шаблон репозитория. См. Ответы на вопрос Repository pattern tutorial in C#.