Pull to refresh
27
0
Ibrakhim Nikishin @IbrahimKZ

lead iOS dev

Send message

Спасибо за статью. Из статьи, как я понял, вы сами на 100% не уверены зачли ли Вам членство в IEEE за пункт членства в ассоциациях. Сколько пунктов Вы в общем хотели закрыть в своей петиции? Одобрили сразу без RFE?

Евгений Ёлчев красит кнопки на iOS, вроде

Они и не зависят. presenter.currencyPickerView и presenter.view в презенторе известны лишь как некие объекты, соответствующие протоколам, о которых знает презентор. Сами currencyPickerView и view уже зависят от UIKit. Но в тестах вам необязательно создавать будет реальные
CurrencyPickerView: UIView, UIPickerViewDataSource, UIPickerViewDelegate, CurrencyPickerViewProtocol и MainViewController: UIViewController, MainViewProtocol, UITextFieldDelegate

Их можно заменить моками, соответствующим протоколам.
Вы, видимо, проглядели это:
weak var currencyPickerView: CurrencyPickerViewProtocol?

Презентер знает только это:
protocol CurrencyPickerViewProtocol: class {
    var arrayCurrencyNames: [String] { set get }
    var title: String { set get }
    var selectedCurrencyIndex: Int? { set get }
    func reload()
}
А логика работы конкретного вьюконтроллера где описывается?
Какой такой код? У меня нормальный код в рамках примера. Если вы бы написали по-другому, то другой написал бы еще и третьим способом.

Приведите свой пример небольшого приложения для сравнения. Поделитесь с другими, как писать идеальный негрязненький код без никакой архитектуры.
Можете привести пример кода, как это реализовывается на практике. Модели – это логика модулей/вьюконтроллеров или это сервисы/хелперы всего приложения? Вьюконтроллер сам хранит в себе данные и, получается, тогда выполняет 2 роли: вьюшки и контроллера?
Чистота архитектура – это то, где вы будете писать ту или иную часть логики. ГДЕ, а не как. Чистота код – это то, КАК конкретно будет писаться сам код. Это то, к чему вы начали придираться.

Это как, я не знаю, ссать в подъезде, но строго в один и тот же угол. Но ни в коем случае не в другой.

В данном примере по правильной и чистой архитектуре вообще нельзя ссать в подъезде, это надо делать в туалете. А как конкретно и чем вы ссыте – это правильные конструкции кода или чистый код.

Я хотел показать, ГДЕ надо писать определенную часть логики, т.е. в каком слое.
Чистота кода и чистота архитектуры – разные вещи. Я про архитектуру больше хотел сказать и заранее вот это написал в статье:
Вот и промолчал бы лучше. Я уже сказал, почему использовал view?.setInputValue вместо свойства. with: — это просто частность, я же не учу именно так писать.

func urlButtonClicked(with urlString: String?) тут String потому что вьюконтроллер не должен заниматься преобразованием в URL, это делается в интеракторе, а View-компонент знает только строки.

func handle(url: URL) нельзя писать во вьюконтроллере. Это уже логика заточенная будет. Мы должны только сообщать презентору, что нажалась кнопка.

В getAllCurrencies идет проверка на dict внутри saveAllCurrencies есть completion(CurrencyError(description: «Currencies' data format is wrong»)). Есть, конечно, опасность, что ни error ни ответа не придет, но там дописать один else только. Но это рабочий пример, а не приложение для продакшна.

Так это в вайперу вообще отношения не имеет :-)
view.setInputValue(with:...) потому что у inputValue нет геттера и вообще нет такого свойства. И это метод, который обновит UI компонент. А зачем эти хрен пойми какие слои в статье и рассказывается.
Устаревший для тех, кто уже понял, что не надо все писать во вьюконтроллере. Но такие статьи пишут для тех, кто еще не прозрел. Для опытных программистов и команд я не открою ничего нового, конечно.
Ну так я и не говорю, что разделение на слои и модули можно сделать только с помощью VIPER. Если у вас соблюдаются принципы SOLID, Clean Architecture и остального, то почему нет.

VIPER – один из способов решить проблему Massive VC и «лапшекода» и я попытался показать это на примере. Напишете свою реализацию архитектуры с примером. Я бы с удовольствием посмотрел.
SRP и является причиной появления этих слоев в VIPER. Если у вас полностью статичный вьюконтроллер, можете удалить ненужные слои для этого модуля. Каждый модуль может иметь разное количество файлов и классов. Часто в сложных вьюконтроллерах их даже больше, чем перечисленные в VIPER.
VIPER можно назвать MVPI: Model (или те же сервисы), View понятно, Presenter и Interactor. Убери отсюда Interactor, получится MVP. Сделай из ViewController-а контроллер, а не View, получится MVC. Лично мне понравился VIPER хоть для маленького, хоть для большого приложения. Если вам по душе другая архитектура проблем нет. Статья же про рабочий пример на VIPER, а не про то, что это лучшая архитектура на свете.
Так ругают то, что расхлябанность в MVC приводит к гигантским вьюконтроллерам. Расскажите, что можно писать во вьюконтроллере, а что нет?
Ну так VIPER и выделяет слои из вьюконтроллера в презентер и интерактор. Названия тут не важны, я про это тоже указывал в статье.

Information

Rating
Does not participate
Location
Алматы (Алма-Ата), Алма-Атинская обл., Казахстан
Date of birth
Registered
Activity

Specialization

Mobile Application Developer
Lead
From 10,000 $
iOS development