Значение фабричного образца - PullRequest
0 голосов
/ 25 февраля 2019

Что является основным смыслом использования фабричного шаблона?

  • В начале у нас есть простая фабрика
class FanFactory : IFanFactory
{
    public IFan CreateFan(FanType type)
    {
        switch (type)
        {
            case FanType.TableFan:
                return new TableFan();
            case FanType.CeilingFan:
                return new CeilingFan();
            case FanType.ExhaustFan:
                return new ExhaustFan();
            default:
                return new TableFan();
        }
    }
}

Хотя это нарушает принцип SOLID,это кажется логичным.Используя один объект фабрики, я могу создать любой другой.

  • Метод фабрики
static void Main(string[] args)
{
    IFanFactory fanFactory = new PropellerFanFactory();
    IFan fan = fanFactory.CreateFan();
    fan.SwitchOn();
    Console.ReadLine();
}

В этом случае я мог бы также сделать:

IFan fan = new PropellerFan();
fan.SwitchOn();

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

Ссылка на примеры

Ответы [ 2 ]

0 голосов
/ 25 февраля 2019

Вы правы, что фабрика сама нарушает принцип ОТКРЫТО / ЗАКРЫТО, поскольку она статически связана с типами, которые она создает.То же самое происходит в вашей абстрактной фабрике, поскольку вы только вводите дополнительный уровень абстракции.Не фабрика решает, какой тип создавать, а код, который создает фабрику.

Но на самом деле у вас есть , чтобы выполнить переключение где-нибудь.Этот код, вероятно, нарушит некоторые принципы.Это компромисс, который вы должны делать довольно часто в программировании.Однако считается более низкой цена за более высокий выигрыш: вместо того, чтобы менять каждый код клиента, когда вы вводите новый тип, вы должны сделать это только один раз на фабрике .Таким образом, весь потребительский код может остаться без изменений.

Еще одно преимущество заключается в том, что ваш клиентский код полностью не знает о реальном классе.Это не нужно знать.На самом деле реальный класс может быть даже произвольной насмешкой.Таким образом, вы можете протестировать свой клиентский код, даже если зависимость (фактически класс, который реализует IFan) еще не существует или только частично разработана другим членом команды:

// there´s currently no valid implementation for the interface, 
// however we don´t care for it, we´re just interested in our own class
// Thus we mock that dependency away
IFan mock = new Mock<IFan>();
systemUnderTest.DoSomething(mock.Object);
0 голосов
/ 25 февраля 2019

Заводской шаблон позволяет:

  • заменять конструкторы классов.Таким образом, вы можете использовать IoC ( Inversion Of Control )
  • Если ваше приложение использует IoC, то вы можете легко написать модульные тесты.Поскольку ваш код слабо связан,
  • откладывает создание конкретной реализации класса.Таким образом, тип класса может быть определен во время выполнения.

Например:

public YourClass(IYourDependency dep) { }

Затем вы можете использовать свою фабрику для создания зависимости:

var dep = new FanFactory.CreateFan(...)// An example of IoC
var cl = new YourClass(dep);

И тогда вы можете смоделировать свою зависимость в модульных тестах:

var dep = new Mock<IYourDependency>().Object;
var cl= new YourClass(dep);
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...