Если вы пропустили первую часть, самое время наверстать упущенное!
Представляем полиморфное создание с фабричным методом
Если классы в иерархии (суперкласс, подклассы) реализуют метод аналогичным образом, за исключением этапа создания объекта, то лучше делегировать процесс создания объекта фабричному методу.
Пример
У нас есть класс XMLBuilder для вывода XML. Затем мы решили работать с подходом TDD и создали класс XMLBuilderTest, который наследуется от суперкласса RandomTest.
Затем мы решили создать DOMBuilder, чтобы пользователи могли редактировать XML-структуру. Очевидно, нам нужен отдельный класс DOMBuilderTest для модульного тестирования нашего нового построителя. Идея заключалась в том, чтобы сделать XMLBuilder и DOMBuilder использовать один и тот же тип, то есть OutputBuilder.
Наш новый класс DOMBuilderTest имеет методы, аналогичные XMLBuilderTest, и дополнительные собственные методы тестирования. Единственная разница заключалась в коде создания, в котором вместо XMLBuilder мы создали экземпляр DOMBuilder. Это большая часть кода дублирования. Если позже мы решим изменить методы тестирования XMLBuiderTest, нам придется изменить их и в классе DOMBuilderTest.
Наконец, мы вводим абстрактный класс, то есть протокол в swift под названием AbstractRandomTest, и добавляем к нему свойство построителя и метод testAddRoot (). Мы создаем абстрактный метод createBuilder () - ›OutputBuilder, который выполняет роль фабричного метода и переопределяется в подклассах, т.е. вводит полиморфное создание в наши код.
Продолжение следует…
