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

Question

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

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 .

Стоимость понимания Фабрики Абстракция

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

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

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

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

Краткое описание

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

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

Answer 2

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