«У каждого свой VIPER». Автор неизвестен
В данной статье я хотел бы рассмотреть архитектуру VIPER на небольшом конкретном примере, который в того же время показывал всю мощь этой архитектуры и был написан на последнем Swift 4. Для тех, кто хочет сразу глянуть код, не читая всю статью, ссылка на реп в самом низу.
Перевод статьи Mark Seemann о популярных архитектурах разработки ПО и о том, что между ними общего.
Один из моих читателей спросил меня:
Вернон, в своей книге «Implementing DDD» много говорит об архитектуре Порты и Адаптеры, как о более продвинутом уровне Слоистой Архитектуры. Хотелось бы услышать ваше мнение на этот счёт.
Если не вдаваться в детали, то в своей книге я описываю именно этот архитектурный паттерн, хотя никогда не называю его этим именем.
TL;DR Если применить принцип инверсии зависимостей к слоистой архитектуре, то в конечном счете получим Порты и Адаптеры.
Читать полностью »
Вводная часть (со ссылками на все статьи)
В водной статье я уже писал о том, что планируемым клиентом для проекта должен стать клиент Android: доступный большой аудитории, лёгкий, функциональный, красивый, быстрый (не приложение, а мечта!). Если с основаниями выбора платформы всё понятно, то с тем как реализовывать на базе неё все перечисленные требования – ясно было далеко не всё.
Ранее разработкой под Android не занимался поэтому достаточно ценными источниками информации для меня являлись:
После изучения указанных источников вопросов с архитектурой Android и взаимодействия их компонентов не осталось. Однако остался один наиважнейший вопрос: какова будет структура самого приложения? Пара примеров и прототипов показала, при росте функционала всё быстро начинало превращаться в «лапшу»:
На первый взгляд, Clean Architecture – довольно простой набор рекомендаций к построению приложений. Но и я, и многие мои коллеги, сильные разработчики, осознали эту архитектуру не сразу. А в последнее время в чатах и интернете я вижу всё больше ошибочных представлений, связанных с ней. Этой статьёй я хочу помочь сообществу лучше понять Clean Architecture и избавиться от распространенных заблуждений. Читать полностью »
В первой части представлена концепция Red Architecture — подход, упрощающий взаимодействие между компонентами в сложных системах, и предназначенная в первую очередь для клиентских приложений. Для полного понимания текущей статьи необходимо познакомиться с данной концепцией здесь.
По следам свежих комментариев к первой части рассмотрим законченный пример, демонстрирующий применение Red Architecture для решения нетривиальной задачи.
У нас есть клиетское приложение — редактор таблиц, в нём отображается лист таблицы. Экран у пользователя настолько большой, что на нём помещается 1 000 000 000 (один миллиард) табличных ячеек. Всё усложняется тем, что наш табличный редактор подключен к облаку для возможности совместного редактирования таблицы, поэтому изменения в любой из одного миллиарда ячеек “где-то в облаке” должны быть сразу же отображены нашему пользователю.
Паттерн Red Architecture позволяет реализовать данную функцию просто и с высокой производительностью.
Читать полностью »
Всё просто. Любому явлению, которое претендует на определённый уровень целостности, необходим идентификатор. На такой идентификатор люди ссылаются в обсуждениях и сразу становится понятно о чём речь. В случае с архитектурой не стоит делать попытку описать в названии суть, любая архитектура это сложная вещь. Поэтому — просто Red!
Основная суть всех архитектурных нововведений в уменьшении связей в коде, т.н. code decoupling. И как следствие, улучшение тестируемости, поддержки, упрощению ввода новых функций и т.д. Но пока ни одна архитектура не признана “идеальной”, остаётся много неприкладных проблем, над которыми программисты ломают голову. Предложения по улучшению архитектур будут продолжаться до тех пор пока “идеальная” архитектура не будет найдена, т.е., вероятно будут продолжаться всегда.
Задача Red Architecture — свести сложность реализации логики приложения к минимуму, оставляя при этом нетронутыми возможность применения и все преимущества других паттернов проектирования.
Red Architecture имеет один класс, необходимый для своей реализации, и четыре соглашения.
Всем привет. На прошедшем Google I/O нам наконец представили официальное видение компании Google на архитектуру Android-приложений, а также библиотеки для его реализации. Не прошло и десяти лет. Конечно мне сразу захотелось попробовать, что же там предлагается.
В этой статье мы хотели бы поделиться опытом использования набирающей популярность библиотеки для хранения данных — Realm. Перед любым проектом вначале разработки встает вопрос что использовать для хранения данных — что-то проверенное или попробовать инструменты из разряда для хипстеров.
Мы — небольшой стартап, разрабатывающий детский лаунчер. Хотя мы стартап и у нас небольшая команда, но большое внимание мы уделяем качеству кода. За два года разработки довольно сильно менялись требования, функционал и выбранные нами технологии. Вплоть до того, что мы перешли с полностью нативного приложения на гибридное, на основе Cordova. Также, одним из этих изменений стал переход с BaaS от Facebook'а Parse на Realm. В этой статье мы хотим рассказать о проблемах, с которыми мы столкнулись при переходе на Realm и стоит ли пробовать новые библиотеки, если со старыми уже "подружились".Читать полностью »
Приветствую уважаемых жителей Хабрахабра!
Не так давно я стал замечать, что мой код становится громоздким и даже в рамках одного контроллера мне все сложней удержать в голове то, что в нем происходит. Как следствие, на выходе не всегда ожидаемый результат, что я хотел реализовать, так как мозг “замылился” и я легко могу упустить существенную деталь. А после, ручной анализ кода, работа с отладчиком и так далее… Да что уж говорить, доходило до абсурда, при сборке приложения xcode падал замертво и я даже не успевал понять, что случилось в приложении! Нужно было что то менять и думать над архитектурой, так как я не хочу всю свою карьеру писать плохоподдерживаемый код…
Кому интересен вопрос архитектуры приложения, добро пожаловать под кат!Читать полностью »
