Алгоритмы – одна из центральных тем в программировании, они повсюду (особенно на собеседованиях, ха-ха).


(Разве можно обойтись в таком посте без «баяна»?)

Одним из самых известных является так называемый алгоритм Евклида – пожалуй, самый распространенный способ нахождения наибольшего общего делителя (НОД) двух целых неотрицательных чисел. С него также зачастую любят начинать изучение (и обучение) соответствующих разделов математики и информатики.

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

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

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

Мир современного программирования богат на тренды, а для мира программирования «iOS»-приложений это справедливо вдвойне. Надеюсь, я не сильно ошибусь, утверждая, что одним из самых «модных» архитектурных шаблонов последних лет является «координатор». Вот и наша команда какое-то время назад осознала непреодолимое желание попробовать на себе этот прием. Тем более, что подвернулся очень удачный случай – значительное изменение логики и тотальная перепланировка навигации в приложении.

Как-то раз я (ну ладно, даже не я) столкнулся с задачей добавить в UICollectionView с определенным типом ячеек одну ячейку совершенно другого типа, причем делать это лишь в особенном случае, который обрабатывается «выше» и никак не зависит от UICollectionView напрямую. Задача эта породила, если мне не изменяет память, пару-тройку уродливых if-else-блоков внутри методов UICollectionViewDataSource и UICollectionViewDelegate, которые благополучно осели в «production»-коде и, наверное, никуда оттуда уже не денутся.

В рамках упомянутой задачи смысла продумывать какое-либо более элегантное решение, тратить на это время и «думательную» энергию, не было. Тем не менее эта история мне запомнилась: я размышлял над тем, чтобы попробовать реализовать некий «datasource»-объект, который бы мог составляться из любого числа других «datasource»-объектов в единое целое. Решение, очевидно, должно быть обобщенным, подходить для любого числа составляющих (включая ноль и один) и не зависеть от конкретных типов. Оказалось, что это не только реально, но и не слишком сложно (хотя сделать код при этом еще и «красивым» – немного труднее).

Если в вашем приложении есть функция регистрации, включающая в себя возможность или необходимость ввода новых имени пользователя и пароля, скорее всего, вас заинтересует нововведение в «iOS 12», которое я хотел бы обрисовать. Это сервис, который придумывает новые пароли для пользователя, автоматически подставляет их в нужные поля и безопасно хранит в «Keychain».

«Итератор» – один из шаблонов проектирования, которые программисты чаще всего не замечают, потому что его реализация, как правило, встроена непосредственно в стандартные средства языка программирования. Тем не менее, это тоже один из поведенческих шаблонов, описанных в книге «Банды четырех» (“Gang of Four”, “GoF”) “Шаблоны проектирования” (“Design Patterns: Elements of Reusable Object-Oriented Software”), и понимать его устройство никогда не помешает, а иногда даже может в чем-то помочь.

«Посетитель» (“Visitor”) – это один из поведенческих шаблонов, описанных в хрестоматийной книге «банды четырех» (“Gang of Four”, “GoF”) “Шаблоны проектирования” (“Design Patterns: Elements of Reusable Object-Oriented Software”).

Даже для самого что ни на есть начинающего разработчика (скорее, на которого и рассчитан данный очерк), надеюсь, не секрет, что в коде не должно присутствовать никаких т.н. «hardcoded»-значений и прочих всяких там «magic numbers». Почему – тоже, надеюсь, понятно, а если нет, то в Сети имеются десятки, а то и сотни статей на эту тему, а также написан классический труд. «Android Studio» (наверное, не во всех случаях, но все же) даже любит генерировать «warnings» на эту тему и предлагать выносить строки и т.д. в ресурсные файлы. «Xcode» (пока?) такими подсказками нас не балует, и разработчику приходится самостоятельно держать себя в узде или, скажем, получать по рукам от коллег после «code review».

Все это касается и используемых в приложении цветов.

Хоть Apple и написали, казалось бы, подробную документацию о том, как можно использовать «Swift»-код внутри «Objective-C»-приложения (и наоборот), но, когда доходит до дела, этого почему-то окаывается недостаточно. Когда у меня впервые появилась необходимость обеспечить совместимость фреймворка, написанного полностью на «Swift», с «Objective-C»-приложением, документация «Apple» почему-то породила больше вопросов, чем дала ответов (ну или по крайней мере оставила множество пробелов). Интенсивное использование поисковых систем показало, что данная тема освещена в Сети довольно скудно: парочка вопросов на StackOverflow, пара-тройка вводных статей (на англоязычных ресурсах, конечно) – вот и все, что удалось найти.

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