Выявление и понимание шаблонов проектирования
Если вы не читали Часть 1 Реализация оповещений iOS с помощью шаблона Factory вот ссылка.
Кроме того, пожалуйста, просто используйте мои примеры как гильдию того, что возможно. Код можно бесконечно улучшать, и он бесконечно меняется. Другими словами, всегда есть лучшие способы что-то закодировать.
Кроме того, я хотел бы упомянуть, что присвоение имен моим переменным, классам, структурам и т. д. всегда было для меня проблемой, и я еще не главный инженер, поэтому мне тоже есть чему поучиться. Не сказать, что главный инженер идеален и все знает, но это то, к чему я сейчас стремлюсь в своем карьерном росте.
Достаточно, я не хочу тратить слишком много времени на определения различных шаблонов, поэтому я упомяну только некоторые ссылки, которые, как я считаю, полезны для объяснения того, что представляет собой каждый шаблон. Я объясню, как я их использую, как их идентифицировать и какие преимущества они дают.
Ресурсы для Factory Pattern
Вот некоторые чтения, которые я рекомендую по фабричному шаблону:
- https://www.raywenderlich.com/books/design-patterns-by-tutorials/v3.0/chapters/11-factory-pattern
- https://stevenpcurtis.medium.com/the-factory-pattern-using-swift-b534ae9f983f
Ресурсы для шаблона Builder
Вот некоторые материалы, которые я рекомендую по шаблону Builder:
- https://www.geeksforgeeks.org/builder-design-pattern/
- https://www.tutorialspoint.com/design_pattern/builder_pattern.htm
Ознакомьтесь с этой историей, чтобы узнать больше о шаблоне 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 быстро!