Идентифициране и разбиране на дизайнерски модели
Ако не сте прочели част 1 от „Внедряване на сигнали за iOS с фабричния шаблон“, „ето връзката“.
Също така, моля, просто използвайте моите примери като гилдия за това какво е възможно. Кодът може безкрайно да се подобрява и безкрайно се променя. С други думи, винаги има по-добри начини да се кодира нещо.
Също така бих искал да спомена, че наименуването на моите променливи, класове, структури и т.н. винаги е било предизвикателство за мен и все още не съм главен инженер, така че и аз имам какво да уча. Не казвам, че главният инженер е перфектен и знае всичко, но това е, към което в момента се стремя в собственото си кариерно развитие.
Достатъчно, не искам да губя твърде много време за дефинициите за различни модели, така че ще спомена само някои връзки, които вярвам, че са полезни, за да обяснят какво представлява всеки модел. Ще обясня как ги използвам, как да ги идентифицирам и ползите за тях.
Ресурси за Factory Pattern
Ето някои четива, които препоръчвам за 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 Pattern
Ето някои четива, които препоръчвам за модела на строителя:
- https://www.geeksforgeeks.org/builder-design-pattern/
- https://www.tutorialspoint.com/design_pattern/builder_pattern.htm
Вижте тази история, за да научите повече за Factory vs. Builder Pattern
Идентифициране на употребите на тези модели в моето внедряване на предупреждение
Забележете как моят AlertImplementation прави само едно нещо. Създава UIAlertController. Мога да използвам тази функция за изграждане, за да създам нов UIAlertController.
Фабричен протокол ще върне нови обекти.
Ако сте чели Factory Pattern Using Swift, ще сте прочели този цитат. Въпреки това, както казах преди, кодът може безкрайно да се подобрява.
Например, като го гледам сега, вместо да извикам тази функция build, трябваше да я извикам за create, тъй като тя винаги създава нов UIAlertController.
Функцията ми за фабрично изграждане приема AlertViewData. Ето как използвах Builder Pattern. Builders обикновено имат функции за настройка и getter за сглобяване на новия обект.
В Swift обаче не използваме гетери и въпреки че нямам функции за настройка, имам тези елементи, които трябва да се задават всеки път, когато създаваме нов AlertViewData.
Builderсъздава Продукт точно както направи Factory. Но сега, вместо само една заявка за създаване на продукта, има няколко извиквания на методи в Builder. Всяко обаждане добавя нова част към продукта. Когато Builder е снабден с всичко необходимо, неговият метод get() може да бъде извикан за сглобяване на новия продукт с елементите, които Builder е получил преди.
Хавиер Гонзалес върши отлична работа, обяснявайки разликата с примери за това как се използват, следователно защо го свързах тук. Затова го последвайте, ако още не сте го направили.
Когато ги събирате заедно, можете да създадете един alertFactory, който ще използва всеки AlertViewData Builder, който искате. По-горе е прост пример за това как да го използвате.
Предимства от използването на тези модели
Ако прочетете точките, които свързах по-горе, вече знаете ползите от използването на всеки модел.
Но можем да отидем още по-далеч и да комбинираме това с други модели. Например, когато комбинирате това с ViewModel и някои услуги, е невероятно какво можете да направите с него.
Тук имаме AlertService специфично за влизане в приложение. Можем да използваме нашия конструктор, за да изградим всички видове предупреждения тук, без всъщност да използваме нашия фабричен метод, докато не сме готови да ги покажем.
Някои методи и променливи са премахнати от кода по-долу, така че може да не работи, ако просто копирате и поставите, а просто го прочетете като общо ръководство за това как го използвам.
ViewModel ще използва и инициализира нашия SignInAlertService, за да реши кои предупреждения за грешка да покаже при валидиране.
По-долу е контролер, който използва отделен SignInView като свой изглед. Тук се упражнявах да използвам контролера за междинното звено между ViewModel и View. Това помогна да се намали броят на редовете в тези ViewControllers.
SignInController ще инициализира AlertFactory, който ще се използва, когато трябва да създадем нов сигнал от методите на делегиране на нашия ViewModel.
Сега отделихме данните от изгледа и използвахме един екземпляр alertFactory, за да създадем множество предупреждения въз основа на AlertViewData на SignInAlertService.
Моля, уведомете ме, ако имате въпроси или смятате, че има по-добър начин да направите това.
Ще ви оставя с това. Научете се да кодирате iOS приложения по бърз начин!
