«Фабричный метод» и «Абстрактная фабрика» во вселенной «Swift» и «iOS»

    Слово «фабрика» – безусловно одно из самых часто употребляемых программистами при обсуждении своих (или чужих) программ. Но смысл в него вкладываемый бывает очень разным: это может быть и класс, порождающий объекты (полиморфно или нет); и метод, создающий экземпляры какого-либо типа (статический или нет); бывает, и даже просто любой порождающий метод (включая, конструкторы).

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

    А на написание этого очерка меня вдохновил Джошуа Керивски (глава «Industrial Logic»), а точнее, его книга «Refactoring to Patterns», которая вышла в начале века в рамках серии книг, основанной Мартином Фаулером (именитым автором современной классики программирования – книги «Рефакторинг»). Если кто-то не читал или даже не слышал о первой (а я знаю таких много), то обязательно добавьте ее себе в список для чтения. Это достойный «сиквел» как «Рефакторинга», так и еще более классической книги – «Приемов объектно-ориентированного проектирования. Паттерны проектирования».

    Книга, помимо прочего, содержит в себе несколько десятков рецептов избавления от различных «запахов» в коде с помощью шаблонов проектирования. В том числе и три (как минимум) «рецепта» на обсуждаемую тему.

    Абстрактная фабрика


    Керивски в своей книге приводит два случая, когда применение этого шаблона будет полезным.

    Первый – это инкапсуляция знаний о конкретных классах, связанных общим интерфейсом. В таком случае этими знаниями будет обладать лишь тип, являющейся фабрикой. Публичный API фабрики будет состоять из набора методов (статических или нет), возвращающих экземпляры типа общего интерфейса и имеющих какие-либо «говорящие» названия (чтобы понимать, какой метод необходимо вызвать для той или иной цели).

    Второй пример очень похож на первый (и, в общем-то, все сценарии использования паттерна более-менее подобны друг другу). Речь идет о случае, когда экземпляры одного или нескольких типов одной группы создаются в разных местах программы. Фабрика в этом случае опять-таки инкапсулирует знания о создающем экземпляры коде, но с несколько иной мотивацией. Например, это особенно актуально, если процесс создания экземпляров этих типов сложный и не ограничивается вызовом конструктора.

    Чтобы быть ближе к теме разработки под «iOS», удобно упражняться на подклассах UIViewController. И действительно, это точно один из самых распространенных типов в «iOS»-разработке, почти всегда «наследуется» перед применением, а конкретный подкласс при этом зачастую даже и не важен для клиентского кода.
    Я постараюсь сохранять примеры кода как можно ближе к классической реализации из книги «Банды четырех», но в реальной жизни часто код бывает упрощенным тем или иным образом. И лишь достаточное понимание шаблона открывает двери для его более вольного использования.

    Подробный пример


    Предположим, мы в приложении торгуем средствами передвижения, и от типа конкретного средства зависит отображение: мы будем использовать разные подклассы UIViewController для разных средств передвижения. Помимо этого, все средства передвижения различаются состоянием (новые и б/у):

    enum VehicleCondition{
        case new
        case used
    }
    
    final class BicycleViewController: UIViewController {
        
        private let condition: VehicleCondition
        
        init(condition: VehicleCondition) {
            self.condition = condition
            super.init(nibName: nil, bundle: nil)
        }
        required init?(coder aDecoder: NSCoder) {
            fatalError("BicycleViewController: init(coder:) has not been implemented.")
        }
        
    }
    
    final class ScooterViewController: UIViewController {
        
        private let condition: VehicleCondition
        
        init(condition: VehicleCondition) {
            self.condition = condition
            super.init(nibName: nil, bundle: nil)
        }
        required init?(coder aDecoder: NSCoder) {
            fatalError("ScooterViewController: init(coder:) has not been implemented.")
        }
        
    }

    Таким образом, у нас есть семейство объектов одной группы, экземпляры типов которых создаются в одних и тех же местах в зависимости от какого-то условия (например, пользователь нажал на товар в списке, и в зависимости от того, самокат это или велосипед, мы создаем соответствующий контроллер). Конструкторы контроллеров имеют некоторые параметры, которые также необходимо каждый раз задавать. Не свидетельствуют ли эти два довода в пользу создания «фабрики», которая одна будет обладать знаниями о логике создания нужного контроллера?

    Конечно, пример достаточно простой, и в реальном проекте в похожем случае вводить «фабрику» будет явным «overengineering». Тем не менее, если представить, что типов транспортных средств у нас не два, а параметров у конструкторов – не один, то преимущества «фабрики» станут более очевидными.

    Итак, объявим интерфейс, который будет играть роль «абстрактной фабрики»:

    protocol VehicleViewControllerFactory {
        func makeBicycleViewController() -> UIViewController
        func makeScooterViewController() -> UIViewController
    }

    (Довольно краткий «гайдлайн» по проектированию «API» на языке «Swift» рекомендует называть «фабричные» методы начиная со слова «make».)

    (Пример в книге банды четырех приведен на «C++» и основывается на наследовании и «виртуальных» функциях. Используя «Swift» нам, конечно, ближе парадигма протокольно-ориентированного программирования.)

    Интерфейс абстрактной фабрики содержит всего два метода: для создания контроллеров для продажи велосипедов и самокатов. Методы возвращают экземпляры не конкретных подклассов, а общего базового класса. Таким образом, ограничивается область распространения знаний о конкретных типах пределами той области, в которой это действительно необходимо.

    В качестве «конкретных фабрик» будем использовать две реализации интерфейса абстрактной фабрики:

    struct NewVehicleViewControllerFactory: VehicleViewControllerFactory {
        
        func makeBicycleViewController() -> UIViewController {
            return BicycleViewController(condition: .new)
        }
        func makeScooterViewController() -> UIViewController {
            return ScooterViewController(condition: .new)
        }
        
    }
    
    struct UsedVehicleViewControllerFactory: VehicleViewControllerFactory {
        
        func makeBicycleViewController() -> UIViewController {
            return BicycleViewController(condition: .used)
        }
        func makeScooterViewController() -> UIViewController {
            return ScooterViewController(condition: .used)
        }
        
    }

    В данном случае, как видно из кода, конкретные фабрики отвечают за транспортные средства разного состояния (новые и подержанные).

    Создание нужного контроллера отныне будет выглядеть примерно так:

    let factory: VehicleViewControllerFactory = NewVehicleViewControllerFactory()
    let vc = factory.makeBicycleViewController()

    Инкапусляция классов с помощью фабрики


    Теперь вкратце пробежимся по примерам использования, которые предлагает в своей книге Керивски.

    Первый «кейс» связан с инкапсуляцией конкретных классов. Для примера возьмем те же контроллеры для отображения данных о транспортных средствах:

    final class BicycleViewController: UIViewController { }
    final class ScooterViewController: UIViewController { }

    Предположим, мы имеем дело с каким-либо отдельным модулем, например, подключаемой библиотекой. В этом случае объявленные выше классы остаются (по умолчанию) internal, а в качестве публичного «API» библиотеки выступит фабрика, которая в своих методах возвращает базовые классы контроллеров, таким образом оставляя знания о конкретных подклассах внутри библиотеки:

    public struct VehicleViewControllerFactory {
        
        func makeBicycleViewController() -> UIViewController {
            return BicycleViewController()
        }
        func makeScooterViewController() -> UIViewController {
            return ScooterViewController()
        }
        
    }

    Перемещение знаний о создании объекта внутрь фабрики


    Второй «кейс» описывает сложную инициализацию объекта, и Керивски, в качестве одного из путей упрощения кода и оберегания принципов инкапсуляции, предлагает ограничение распространения знаний о процессе инициализации пределами фабрики.

    Предположим, мы захотели продавать заодно уж и автомобили. А это, несомненно, более сложная техника, обладающая бóльшим числом характеристик. Для примера ограничимся типом используемого топлива, типом трансмиссии и размером колесного диска:

    enum Condition {
        case new
        case used
    }
    
    enum EngineType {
        case diesel
        case gas
    }
    
    struct Engine {
        let type: EngineType    
    }
    
    enum TransmissionType {
        case automatic
        case manual
    }
    
    final class CarViewController: UIViewController {
        
        private let condition: Condition
        private let engine: Engine
        private let transmission: TransmissionType
        private let wheelDiameter: Int
        
        init(engine: Engine,
             transmission: TransmissionType,
             wheelDiameter: Int = 16,
             condition: Condition = .new) {
            self.engine = engine
            self.transmission = transmission
            self.wheelDiameter = wheelDiameter
            self.condition = condition
            
            super.init(nibName: nil, bundle: nil)
        }
        required init?(coder aDecoder: NSCoder) {
            fatalError("CarViewController: init(coder:) has not been implemented.")
        }
        
    }

    Пример инициализации соответствующего контроллера:

    let engineType = EngineType.diesel
    let engine = Engine(type: engineType)
    
    let transmission = TransmissionType.automatic
    
    let wheelDiameter = 18
    
    let vc = CarViewController(engine: engine,
                               transmission: transmission,
                               wheelDiameter: wheelDiameter)

    Мы можем ответственность за все эти «мелочи» водрузить на «плечи» специализированной фабрики:

    struct UsedCarViewControllerFactory {
        
        let engineType: EngineType
        let transmissionType: TransmissionType
        let wheelDiameter: Int
        
        func makeCarViewController() -> UIViewController {
            let engine = Engine(type: engineType)
            return CarViewController(engine: engine,
                                     transmission: transmissionType,
                                     wheelDiameter: wheelDiameter,
                                     condition: .used)
        }
        
    }

    И создавать контроллер уже таким образом:

    let factory = UsedCarViewControllerFactory(engineType: .gas,
                                               transmissionType: .manual,
                                               wheelDiameter: 17)
    let vc = factory.makeCarViewController()

    Фабричный метод


    Второй «однокоренной» шаблон также инкапсулирует знания о конкретных порождаемых типах, но не за счет сокрытия этих знаний внутри специализированного класса, а за счет полиморфизма. Керивски в своей книге приводит примеры на «Java» и предлагает пользоваться абстрактными классами, но обитатели вселенной «Swift» с таким понятием не знакомы. У нас тут своя атмосфера… и протоколы.
    Книга «Банды четырех» сообщает, что шаблон также известен под названием «виртуальный конструктор», и это не зря. В «C++» виртуальной называется функция, переопределяемая в производных классах. Возможности объявить виртуальным конструктор язык не дает, и не исключено, что именно попытка сымитировать нужное поведение привела к изобретению данного паттерна.

    Полиморфное создание объектов


    В качестве классического примера пользы шаблона рассмотрим случай, когда в иерархии разные типы имеют идентичную реализацию одного метода за исключением объекта, который в этом методе создается и используется. В качестве решения предлагается создание этого объекта вынести в отдельный метод и реализовывать его отдельно, а общий метод – поднять выше в иерархии. Таким образом, разные типы будут использовать общую реализацию метода, а объект, необходимый для этого метода, будет создаваться полиморфно.

    Для примера вернемся к нашим контроллерам для отображения транспортных средств:

    final class BicycleViewController: UIViewController { }
    final class ScooterViewController: UIViewController { }

    И предположим, что для их отображения используется некая сущность, например, координатор, который представляет эти контроллеры модально из другого контроллера:

    protocol Coordinator {
        var presentingViewController: UIViewController? { get set }
        func start()
    }

    При этом метод start() используется всегда одинаково, за исключением того, что в нем создаются разные контроллеры:

    final class BicycleCoordinator: Coordinator {
        
        weak var presentingViewController: UIViewController?
        
        func start() {
            let vc = BicycleViewController()
            presentingViewController?.present(vc, animated: true)
        }
        
    }
    
    final class ScooterCoordinator: Coordinator {
        
        weak var presentingViewController: UIViewController?
        
        func start() {
            let vc = ScooterViewController()
            presentingViewController?.present(vc, animated: true)
        }
        
    }

    Предлагаемое решение – это вынести создание используемого объекта в отдельный метод:

    protocol Coordinator {
        
        var presentingViewController: UIViewController? { get set }
        
        func start()
        func makeViewController() -> UIViewController
        
    }

    А основной метод – снабдить базовой реализацией:

    extension Coordinator {
        
        func start() {
            let vc = makeViewController()
            presentingViewController?.present(vc, animated: true)
        }
        
    }

    Конкретные типы в таком случае примут вид:

    final class BicycleCoordinator: Coordinator {
        
        weak var presentingViewController: UIViewController?
        
        func makeViewController() -> UIViewController {
            return BicycleViewController()
        }
        
    }
    
    final class ScooterCoordinator: Coordinator {
        
        weak var presentingViewController: UIViewController?
        
        func makeViewController() -> UIViewController {
            return ScooterViewController()
        }
        
    }

    Заключение


    Я попытался данную несложную тему осветить, совместив три подхода:

    • классическая декларация существования приема, навеянная книгой «Банды четырех»;
    • мотивация использования, неприкрыто вдохновленная книгой Керивски;
    • прикладное применение на примере близкой мне отрасли программирования.

    При этом я попытался быть максимально близким хрестоматийной структуре шаблонов, насколько это возможно, не разрушая принципы современного подхода к разработке под систему «iOS» и используя возможности языка «Swift» (вместо более распространенных «С++» и «Java»).

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

    Надеюсь, хотя бы отчасти мне удалось достичь поставленных целей, а читателю – хотя бы отчасти было интересно или хотя бы любопытно узнать или освежить свои знания по данной теме.

    Другие мои материалы на тему шаблонов проектирования:


    А это ссылка на мой «Twitter», где я публикую ссылки на свои очерки и немного сверх того.

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 4

      +1
      Спасибо за очередную интересную статью.
        0
        Спасибо за «спасибо», приятно!
        +1
        Жаль, что по Свифту на хабре мало столь же полезных публикаций, как эта.
          0
          Да, я тоже так считаю, поэтому по мере сил пытаюсь делать с этим хоть что-то! И вижу ваши успехи на поприще, спасибо за них!

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое