Выявление и понимание шаблонов проектирования

Если вы не читали Часть 1 Реализация оповещений iOS с помощью шаблона Factory вот ссылка.

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

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

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

Ресурсы для Factory Pattern

Вот некоторые чтения, которые я рекомендую по фабричному шаблону:

Ресурсы для шаблона Builder

Вот некоторые материалы, которые я рекомендую по шаблону Builder:

Ознакомьтесь с этой историей, чтобы узнать больше о шаблоне Factory vs. Builder

Идентификация использования этих шаблонов в моей реализации предупреждений

Обратите внимание, как мой AlertImplementation делает только одну вещь. Он создает UIAlertController. Я могу использовать эту функцию сборки для создания нового файла UIAlertController.

Заводской протокол вернет новые объекты.

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

Например, глядя на это сейчас, вместо вызова этой функции build я должен был вызвать ее для создания, поскольку она всегда создает новый UIAlertController.

Моя функция заводской сборки принимает файл AlertViewData. Вот как я использовал шаблон Builder. Строители обычно имеют функции установки и получения для сборки нового объекта.

Однако в Swift мы не используем геттеры, и хотя у меня нет сеттер-функций, у меня есть эти элементы, которые нужно устанавливать каждый раз, когда мы создаем новый AlertViewData.

Builder создает Product так же, как Factory. Но теперь вместо одного запроса на создание Продукта несколько вызовов методов в Билдере. Каждый вызов добавляет к Продукту новую часть. Когда Builder снабжен всем необходимым, можно вызвать его метод get() для сборки нового Product с элементами, которые Builder получил ранее.

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

Собрав их вместе, вы можете создать один alertFactory, который будет использовать любой AlertViewData Builder, который вы хотите. Выше приведен простой пример того, как его использовать.

Преимущества использования этих шаблонов

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

Но мы можем пойти еще дальше и объединить это с другими шаблонами. Например, когда вы комбинируете это с ViewModel и некоторыми услугами, вы можете сделать с этим удивительные возможности.

Здесь у нас есть AlertService для входа в приложение. Мы можем использовать наш конструктор для создания всех видов предупреждений, фактически не используя наш фабричный метод, пока мы не будем готовы их отобразить.

Некоторые методы и переменные были удалены из приведенного ниже кода, поэтому он может не работать, если вы просто скопируете и вставите его, но просто прочитаете его как общее руководство по тому, как я его использую.

ViewModel будет использовать и инициализировать наш SignInAlertService, чтобы решить, какие предупреждения об ошибках показывать при проверке.

Ниже показан контроллер, который использует отдельный SignInView в качестве представления. Здесь я практиковался в использовании контроллера как промежуточного звена между ViewModel и View. Это помогло уменьшить количество строк в этих ViewControllers.

SignInController инициализирует AlertFactory, который будет использоваться, когда нам нужно создать новое оповещение из методов делегата нашей ViewModel.

Теперь мы отделили данные от представления и использовали один экземпляр alertFactory для создания нескольких предупреждений на основе AlertViewData SignInAlertService.

Пожалуйста, дайте мне знать, если у вас есть какие-либо вопросы или вы думаете, что есть лучший способ сделать это.

Я оставлю вас с этим. Научитесь кодировать приложения для iOS быстро!