Тема SOLID-принципов и в целом чистоты кода не раз поднималась на Хабре и, возможно, уже порядком изъезженная. Но тем не менее, не так давно мне приходилось проходить собеседования в одну интересную IT-компанию, где меня попросили рассказать о принципах SOLID с примерами и ситуациями, когда я не соблюл эти принципы и к чему это привело. И в тот момент я понял, что на каком-то подсознательном уровне я понимаю эти принципы и даже могут назвать их все, но привести лаконичные и понятные примеры для меня стало проблемой. Поэтому я и решил для себя самого и для сообщества обобщить информацию по SOLID-принципам для ещё лучшего её понимания. Статья должна быть полезной, для людей только знакомящихся с SOLID-принципами, также, как и для людей «съевших собаку» на SOLID-принципах.

В этой серии статей я соберу бОльшую часть своего опыта разработки на Ruby on Rails. Эти методики позволяют контролировать сложность и облегчают сопровождение проекта. Большинство из них придумал не я, и, по возможности, буду указывать источник.

Основная проблема проектов на RoR в том, что, как правило, всю логику пытаются уместить в модели, контроллеры и представления. Т.е. код находится только в моделях(ActiveRecord::Base), контроллерах, хэлперах и шаблонах. Такой подход приводит к печальным последствиям: код становится запутанным, долго делаются фичи, появляются регрессии, у разработчиков пропадает мотивация. В качестве примера можно посмотреть на исходники redmine.

Выход из данной ситуации довольно-таки очевидный. Будем делать проекты не на ruby on rails, а с использованием ruby on rails. Как это будет выглядеть: мы никуда не уходим от MVC и Rails, просто пересмотрим Model, View, Controller. Для начала расширим понятие модели. Модель — это не просто класс-наследник ORM. Модель — это вся бизнес логика приложения. Модель включает в себя: модели, сервисы, политики, репозитории, формы и другие элементы, которые я опишу далее. Так же расширим представления. Представления — это шаблоны, презентеры, хелперы, билдеры форм. Контроллеры — это все то, что связано с обработкой запросов: контроллеры, responders.

В предыдущей части я рассказал про представления. Теперь поговорим про контроллеры.
В этой части я расскажу про:

• REST
• gem responders
• иерархию контроллеров
• хлебные крошки

Контроллер обеспечивает связь между пользователем и системой:

• получает информацию от пользователя,
• выполняет необходимые действия,
• отправляет результат пользователю.

Контроллер содержит только логику взаимодействия с пользователем:

• выбор view для отображения данных
• вызов процедур обработки данных
• отображение уведомлений
• управление сессиями

Бизнес логика должна храниться отдельно. Ваше приложение может так же взаимодействовать с пользователем через командную строку с помощью rake команд. Rake команды, по сути, те же контроллеры и логика должна разделяться между ними.

14-го ноября на уютной Мансарде офиса Rambler&Co пройдет Global Day of Code Retreat.



Что такое Code Retreat?

Code Retreat — это однодневный интенсивный тренинг для разработчиков, проходящий во многих странах с целью отработки фундаментальных навыков разработки: simple design, SOLID, TDD, парное программирование. Также, это возможность пообщаться, обменяться опытом, расширить свой кругозор. Язык, на котором вы разговариваете (пишете) не имеет значения.

В своей статье хочу рассмотреть пример неправильного, на мой взгляд, использования Dependency Injection принципа и попробовать отыскать мотивацию для других разработчиков команды (а может и кому еще сгодится) писать новый код лучше, а также по мере сталкивания в рамках рабочих активностей с чужим кодом, написанным неграмотным образом, делать рефакторинг.

Итак, суть проблемы. На проекте мы используем OData WebApi и все контроллеры наследуются от базового, используют метод GetService из базового класса который вытягивает зависимости через статический класс ApiControllerScopeContextMediator.

public abstract class ODataControllerBase : ODataController
{		
	protected T GetService<T>()
        {
              return ApiControllerScopeContextMediator.GetService<T>(this);
        }		
}	
internal static class ApiControllerScopeContextMediator
 {		
	internal static T GetService<T>(ApiController controller)
        {
              return (T) controller.Configuration.DependencyResolver.GetService(typeof (T));
        }		
}
	

А в Global.asax конфигурируем подтягивание зависимостей для OData через StructureMap:

    GlobalConfiguration.Configuration.DependencyResolver = new StructureMapDependencyResolver(container);

Во всех action у контроллеров повсеместно используется метод GetService, как, например, здесь:

public class DisconnectedAppsController : ODataControllerBase
{
	public IHttpActionResult Get()
        {		
		var query = GetService<IQuery<IQueryable<DisconnectedAppDomain>, DisconnectedAppFilter>>();		
	}
}

Но почему? Ведь можно было бы просто использовать constructor injection:

public DisconnectedAppsController(IQuery<IQueryable<DisconnectedAppDomain>, DisconnectedAppFilter> query){
    _query = query;
}

Так что же все-таки: «Таити, Таити» (Constructor Injection) или «нас и здесь неплохо кормят» (GetService)?

Эта статья — продолжение статьи C#: коллекции только для чтения и LSP. Сегодня мы посмотрим на интерфейс IEnumerable с точки зрения принципа подстановки Барбары Лисков (LSP), а также разберемся, нарушает ли этот принцип код, имплементирующий IEnumerable.

«Any magic, sufficiently analyzed is indistinguishable from technology.»

Артур Кларк
(эпиграф в официальной wiki проекта Typhoon Framework)

Цикл «Управляем зависимостями в iOS-приложениях правильно»

• Знакомство с Typhoon
• Устройство Typhoon
• Модульность Typhoon
• Typhoon Tips & Tricks
• Альтернативы Typhoon
• (Дополнительно) Rambler.iOS #3. Dependency Injection в iOS. Слайды
• (Дополнительно) Rambler.iOS #3. Dependency Injection в iOS. Видео

Введение

В рамках этого цикла статей я не буду углубляться в теорию, рассматривать Dependency Inversion Principle или паттерны Dependency Injection — примем за данность, что читатель уже достаточно подготовлен к тому, чтобы познать дзен, и перейдем сразу к практике (ссылки для знакомства с теорией даны в самом конце поста).

Typhoon Framework — это самая известная и популярная реализация DI-контейнера для Objective-C и Swift приложений. Проект достаточно молодой — первый коммит был сделан в самом конце 2012 года, но уже обзавелся большим количеством поклонников. Отдельного упоминания заслуживает активная поддержка проекта его создателями (один из которых, между прочим, живет и работает в Омске) — на большинство создаваемых Issue отвечают в течение десяти минут, а уже через несколько часов к обсуждению присоединяется вся команда.

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



Красноярск — далекий сибирский город и глухая it-провинция. Но 30 мая 2015 года нашей активности позавидуют соседи. В этот день состоится вторая конференция разработчиков программного обеспечения Dev2Dev, версия 2.0. Конференцию организует молодое одноименное it-сообщество, объединяющее спецов отрасли из компаний города. Нам менее года, но мы растем. С самого начала мы работали для того, чтобы в Красноярске наконец появилась круто сваренное местное событие с большой активной аудиторией и заезжими докладами.

Концепция событий сообщества Dev2Dev проста: свободный вход, качественный контент и много общения для участников и спикеров. Событие — это в первую очередь фан, знакомства и накачка энергией. Сильные доклады и интересные спикеры делают это возможным, но само событие создают участники. 30 мая мы ждем 200-250 человек. Новая конференция соберет доклады по enterprise разработке, функциональному программированию, проектированию, тестированию приложений, управлению проектами и командой. Докладчики едут со всей Сибири — Новосибирск, Омск, Кемерово. Специальный гость прилетит из Чикаго.

В прошлой части цикла мы познакомились с Dependency Injection фреймворком для iOS — Typhoon, и рассмотрели базовые примеры его использования в проекте Рамблер.Почта. В этот раз мы углубимся в изучение его внутреннего устройства.

Статья 1. Почему я не преподаю SOLID

Если вы разговариваете с кем-то, кому небезразлично качество кода, уже достаточно скоро в разговоре всплывёт SOLID — аббревиатура, помогающая разработчикам запомнить пять важных принципов объектно-ориентированного программирования:

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

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

Сегодня SOLID остается для меня важным, но я больше не пытаюсь сделать мой код SOLID. Я редко упоминаю его, когда говорю про дизайн. И тем более я не учу пользоваться им разработчиков, которым хочется почерпнуть хорошие дизайнерские методы проектирования. Он больше не находится у меня под рукой в моем «ящике для инструментов». Он лежит в пыльной коробке на чердаке. Я храню его, потому что он важен, но редко им пользуюсь.

В предыдущей статье цикла мы кратко рассмотрели основные принципы устройства и функционирования Typhoon Framework — Dependency Injection контейнера для iOS. Тем не менее, мало понимать, как устроен инструмент — важнее всего правильно его использовать. В первой части мы рассматривали различные примеры настройки конфигураций создаваемых зависимостей, то теперь разберемся с более высоким уровнем — разбитием на модули самих TyphoonAssembly и их тестированием.

У нас сотни программных проектов на поддержке, некоторые из них поддерживаются нами почти десять лет. Нетрудно догадаться, что понятие maintainable кода (переведу это понятие как код, легкий в поддержке) является у нас одним из основных. По счастливому стечению обстоятельств легкий в поддержке код также является и легким для (unit-)тестирования, легким для освоения новыми членами команды и т.д. Скорее всего, это связано с тем, что для создания maintainable кода приходится озаботиться хорошей архитектурой проекта и завести несколько хороших привычек.
В этой статье и поговорим о таких привычках, благодаря которым часто хорошая архитектура получается сама собой. Постараюсь также иллюстрировать все хорошими примерами.

Часто ли вы задумываетесь – почему что-то сделано так или иначе? Почему у вас микросервисы или монолит, двухзвенка или трехзвенка? Зачем вам многослойная архитектура и сколько у вас вообще слоев? Что такое бизнес-логика, логика приложения, презентационная логика и почему все так разделено? Посмотрите на свое приложение – как оно вообще спроектировано? Что в нем и где находится, почему это сделано именно так?
Потому что так написано в книжках или так говорят авторитетные личности? Какие ВАШИ проблемы решает тот или иной подход/паттерн?
Даже то, что на первый взгляд кажется очевидным, порой бывает очень сложно объяснить. А иногда, в попытке объяснения, приходит понимание того, что очевидные мысли были и вовсе ошибочны.
Давайте попробуем взять какой-нибудь пример и изучить на нем эти вопросы со всех сторон.

В предыдущих частях цикла мы рассмотрели основные аспекты работы Typhoon и подготовились к полноценному применению его на практике. Тем не менее, помимо затронутых тем, фреймворк предоставляет большое количество других функций.

Статья «Скользящая ответственность паттерна Репозиторий» подняла несколько вопросов, на которые очень сложно дать ответ. Нужен ли репозиторий, если абстрагироваться от технических деталей полностью невозможно? На сколько сложным репозиторий может быть, чтобы его написание оставалось целесообразным? Ответ на эти вопросы различается в зависимости от акцента, который делается при разработке систем. Наверно, самый сложный вопрос: нужен ли, вообще, репозиторий? Проблема «текучей абстракции» и рост сложности кодирования с увеличением уровня абстракции не позволяют найти решение, которое удовлетворяло бы оба лагеря. Например, в репортинге intention design приводит к созданию большого числа методов для каждого фильтра и сортировки, а generic решение создает большой оверхед по кодированию. Продолжать можно бесконечно…

Для более полного представления я взглянул на проблему абстракций со стороны применения их в уже готовом коде, в legacy code. Репозиторий, в таком случае, нас интересует только, как инструмент для достижения качественного и безбажного кода. Конечно, этот паттерн — не единственное, что необходимо для применения TDD практик. Наевшись «невкусной еды» в нескольких больших проектах и наблюдая за тем, что работает, а что нет, я вывел для себя несколько правил, которые мне помогают следовать TDD практикам. С удовольствием выслушаю конструтктивную критику и иные приёмы внедрения TDD.

Давайте глянем на определение принципа инверсии зависимостей из википедии:

Принцип инверсии зависимостей (англ. dependency inversion principle, DIP) — важный принцип объектно-ориентированного программирования, используемый для уменьшения связанности в компьютерных программах. Входит в пятёрку принципов SOLID.

Формулировка:

A. Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
B. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

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

Как и ожидал, правило 8 о том, что не тестируем алгоритм методов в статье "Правила внедрения TDD в старом проекте" вызвало больше всего вопросов «как» и «зачем». В момент составления прошлой статьи мне показалось это очевидным, поэтому не остановился детальнее на этом моменте. Но т.к. вопросов возникло много, хочу описать своё видение. Поэтому под катом будет небольшой пример кода и два примера того, как его можно было бы протестировать.

В этой статье мы попробуем описать один из известных принципов объектно-ориентированного программирования, входящий в аббревиатуру не менее известного понятия SOLID. На английском языке он носит название Single Reponsibility, что в переводе на русский означает Единственность Ответственности.

В оригинальном определении этот принцип гласит:

Класс должен иметь только одну причину для изменения

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

«Божественный» код — громкий термин, который может показаться желтым заголовком, но всё же именно о таком коде будет идти речь: из каких частей он состоит и как его писать. Это история о моих стараниях сделать так, чтобы задачи не возвращались с code review с пометкой: «Всё хе*ня — переделать».

У меня нет профильного образования, и учиться программированию приходилось на практике, через ошибки, ссадины и ушибы. Непрерывно работая над улучшением качества написанного кода, я вырабатывал некоторые правила, которым он должен соответствовать. Хочу ими поделиться.