Artem
@artemvkepke
iOS Developer
Информация
- В рейтинге
- Не участвует
- Откуда
- Москва, Москва и Московская обл., Россия
- Работает в
- Зарегистрирован
- Активность
Специализация
Mobile Application Developer
Senior
iOS development
SWIFT
Objective-C
UIKit
GCD
Спасибо за статью. Интересный материал. Хорошо прям проработан подход, но все-таки думается, что могут существовать ситуации, в которых для реализации бизнес-требований будет выгоднее использовать enum.
Предлагаю рассмотреть такой случай:
пусть в ленте 100500 итемов (ячеек) 15 разных типов (посты, клипы и т.д.) и нужно дать пользователю возможность выбирать из них два итема, но с обязательным условием, что итемы должны быть разных типов.
Например, если первой выбрана ячейка постов, то вторую можно выбрать "только-не-посты" (а например клипы) и наоборот.
Кажется, что тут будет выгоднее оставить пришедший из сети enum и паттерн-матчить по нему.
Если честно выполнить это:
То на основе вышеприведенных тестов нельзя быть уверенным, что метод
createGreeting
вернет "Welcome, ${name}!" для произвольногоname
.Факт 100% покрытия - не может дать такой уверенности потому, что раз мы имеем дело с черным ящиком, то мы должны считать, что не знаем как реализована подстановка строк "Welcome, ${name}!". Например, "Welcome, ${name}!" мог бы для некоторых предопределенных
name
возвращать пустую строку.Выглядит так, что приведенные тесты дают уверенность в правильном поведении, только когда мы прочитали код реализации и точно знаем как работает каждая операция.
Если же мы хотим уверенности работая с черным ящиком - то нам нужен тест проверяющий все варианты
name
. И в плюс к этому нужно откуда-то получить гарантию, чтоcreateGreeting
- чистая (pure) функция.Если нет гарантии чистоты
createGreeting
, то возможность использовать черный ящик пропадает полностью: для уверенности в правильной работеcreateGreeting
нужно прочитать весь её код, найти обращения к методам зависящим от сайд-эффектов и протестировать её для [(все возможные сайд-эффекты) X (все возможные значения агрументов)].Понятно, что для синтетического примера с подстановкой строки приведенные выше рассуждения выглядят надуманными. Но представим, что в
createGreeting
10, или 20, или (как бывает в реальных проектах с миллионами строк кода) 100+ строк. И сразу рассуждения такого рода становятся насущной необходимостью.Будет ли более верным сказать, что на практике TDD может работать только с "белым ящиком"?
Новое мобильное приложение, еще и in-house, и даже статья на Хабре — это повод надеяться, что банк решил повернуться лицом к физическим лицам (каламбур, да).
Насчёт самой статьи: написано как будто для руководства, а не для Хабра.
Аргументирую:
Чтобы починить всё это — стоило бы дать вычитать статью нескольким «свежим» людям.
В завершение: ещё раз желаю успеха в работе!
Хотел бы предложить легенду перенести в начало и скрыть под спойлер для удобства, тех кто и так её знает. «Легенда в конце текста» — заставляет пробежаться вниз-вверх.
Разрешение зависимости с опорой на класс автоматически приводит к:
> Не получится закрыть зависимость протоколом
> Не надо регистрировать зависимости (вообще не надо)
> Извлечение из контейнера никогда не сломается
Эти плюсы и минус — разные стороны одной медали ;)
И перевод здесь точен. Казалось бы, ерунда. Но в итоге, вместо обсуждения примера, который предназначался в определенном контексте иллюстрировать определенные идеи, получается обсуждение того, как плохо, что данный пример — это не образец Абсолютно Идеального Чистого Кода.
«DI (внедрение зависимости, англ. Dependency injection)»
«IoC (Инверсия управления, англ. Inversion of Control)»
Евгений как раз хорошо написал о различиях этих терминов и о том, почему они зачастую упоминаются вместе. У меня в статье больше про DI, конечно. IoC хоть и присутствует в «решении Василия», но явным образом об этом не сказано.
Кстати, рекомендую статью Евгения всем, кому нравится более спокойный стиль изложения. Также мне показалось интересным: взгляд под другим углом, другие акценты, более обширные и приближенные к UIViewController примеры.
Другой вопрос — это тестирование кода, в котором происходит работа с синглтоном. Но опять же, если синглтон инъектить как зависимость закрытую протоколом, то класс, в который синглон инъектирован, тестируется так же как обычно.
То есть с точки зрения тестируемости, синглтон может быть вполне безвреден.
Что касается — тут, да, код выглядит довольно опасным. Все места в программе работающие с синглтоном будут работать с общим проперти dataArray, и если пользователь зачем-то начнёт работать с этим синглтоном из разных потоков, то начнется гонка за dataArray. Результатом станет емнип неопределенное поведение.