Pull to refresh

Comments 50

Вот это да. Огромное спасибо! Это просто титанический труд!

Как-раз собирался прочесть у Рея, а тут вы подоспели с переводом!

P.S. ай-я-яй, искали разработчиков, и не написали ;) в моей команде у всех отличные знания паттернов :)
в моей команде у всех отличные знания паттернов :)

Судя по некоторым вашим статьям, ваша команда хранит эти отличные знания от вас в тайне :)
Чего я на хабре не ожидал, так это подобных оскорблений. В дебри уходить не буду и свои статьи тут рассматривать не буду, но ниже отлично описано, почему в туториалах и статьях иногда важнее показать отдельную технологию, нежели придерживаться стиля идеального программирования.
спасибо за перевод!

Понятно, что плюсы учат по Страуструпу и «банде четырёх», а Objective C — больше по туториалам и Stack Overflow


интересно. я всегда считал, что GoF родился в первую очередь из Smalltalk практики авторов, а Objective C — попытка обеспечить объектное программирование для C, натянув идеи Smalltalk-а, вместо идей Страуструпа. Но сложная судьба инструмента, видимо сказалась.
«2. Забудьте тот ужас, который вы видели на developer.apple.com! Да-да, те примеры, где ViewController'ы играют две-три роли одновременно. — Прим. пер.»

Собственно, этот ужас писали как раз инженеры Apple, те самые, кто занимается и выпуском самих iOS/Mac OS X. Можно сколько угодно тыкать их носом в их корявый код — но он работает и приносит прибыль, не снящуюся никакому коучу (мы же говорим о коммерческом коде, не так ли?).

Я проходил в жизни достаточное количество успешных собеседований, чтобы понять одну простую вещь: идеала нет и быть не может. А меньше всего идеала было там, где на собеседовании тебя закидывали вопросами про паттерны и круглые крышки люков (насчет последнего, кстати, уже не то, чтобы поумнели резко, но сам великий Гугл сказал, что это не работает и вдруг в одночасье такие вопросы стали немодными). И ты такой счастливый, потому что думаешь, что кончился наконец этот бардак в голове и в репозитории и ты, наконец, попал куда нужно, тут сидят Правильные Люди и пишут Правильный Код. Щас же. Говнокод на говнокоде, патч на патче, и особенно у тех самых техлидирующих, кто с сожалением смотрел с той стороны стола переговорки HR отдела на тебя, мычащего незаученно о том, Как Действительно Надо Писать Приложения. Исхода нет.

Одни пишут код, другие учат писать код.

Спасибо за перевод и потраченное время. Такие статьи — как путеводная звезда для нас всех, они позволяют верить во что-то большее. Где-то, где-то есть такие компании, я все еще верю.

этот ужас писали как раз инженеры Apple
Или специально нанятая команда индусов. :) Я больше склоняюсь к такому варианту.

Инженеров Apple NeXT, плодами которых пользуются инженеры Apple, я только хвалю:
а почему не проверили (albumIndex >= 0)? Автор туториала об этом не подумал, а создатели класса NSArray подумали
это все из-за суеты же?
но я помню, как ты сам мне рассказывал про толкового менеджера, настаивавшего на правильном написании кода («чтобы девочка 1С-ца могла понять) и насколько приятнее и легче жить, когда сдаешь именно такой проект, а не „наваленный“
Ну вот я сейчас в роли ПМа затягиваю сроки сдачи проекта исключительно из-за качества кода.
// Не реклама, все вакансии заняты. :)
Поддерживаю. Надеюсь только, что проект достаточно долгосрочный, чтобы Вы успели оправдать свою позицию и доказать выгодность такого подхода.
Отличный и доходчивый перевод! Огромное спасибо!
О! Вещь. :)

Эт я понимаю
Все не читал, но возникло ощущение что еще немного и получится MVVM.
Привет! Я тебя часто вижу в ReactiveCocoa на гитхабе. MVVM пока сложно реализовывать для большинства iOS разработчиков, выращенных на туториалах, все упирается в bindings и непонимание того что ViewController это View Layer, а уж когда они видят код RAC, то и вовсе руки опускаются. Видел этот тикет? )) github.com/ReactiveCocoa/ReactiveCocoa/issues/393
Привет! Да, learning curve у всего этого дела крайне крутая, увы. Тикет крутой :)
В защиту инженеров Apple скажу, что большая часть примеров со спагетти-контроллерами обычно демонстрирует какую-то одну конкретную технологию/фреймворк/класс, а не является примером «как вообще надо писать код»
Можно добавить, что если уж кидать камень в огород кода на известном портале, то не стоит приводить в пример то, что приведено. С магическими числами и строками по всему коду, макросами вместо типизированых констант, стилистическими неоднородностями или моментами, идущими вразрез с общепринятыми соглашениями.
Давно ждал такую статью. Книжка четырех, с их натянутыми примерами на C-smallTalk очень трудно осилить начинающему спецу, имхо.

Огромное спасибо!
Вступление к переводу очень хорошее, но когда увидел что это вандерлих, то стало как-то «странно».
ИМХО, все эти ребята как раз и являются одним из источников зла в ObjC dev мире.
Читабельность из кода — это нечто высокое, величественное.
Во во. Потом приходят такие на работу устраиваться и плывут на первых же вопросах про SOLID, а уж их код весь изобилует myTableView, CustomButton и прочими прелестями скрипт киддисов.
Вы схему для MVC похоже сами нарисовали. И разделение обязанностей видно тоже во сне увидели.

1. Контроллер ничерта не знает о конкретной View, чтобы они были элементарно заменяемы без смены контроллера.
2. Модель никогда не уведомляет контроллер ни о каких своих изменениях. Она уведомляет непосредственно View.

В MVC главный принцип что всё строится вокруг модели. И View и Controller легко заменяемы. View — чтобы сменить представление (консоль, html, вывод в сокет), и контроллер — чтобы сменить логику реагирования (но не бизнес логику).
Тут описан MVC который пропагандирует Apple.
А эппл не пропагандирует внутривенные инъекции героина? Пользы для мира будет больше чем от подобных «MVC» которые даже близко не являются оным.
Так а у вас есть своё собственное мнение? Или вы тоже считаете что эта лютая смесь бреда и MVP имеет право называться MVC и этому нужно учить детей?
Ну тут они называют это Cocoa MVC. Не вижу ничего плохого в адаптации паттернов под фреймворки. Microsoft превратили Фаулеровский MVP в MVVM.
Вот и переводи после этого статьи. :) Значит, Cocoa MVC — вовсе не MVC…

Про детей, боюсь, поздно думать, потому что в Стэнфорде уже 4 года учат именно так (и без приставок типа «Cocoa MVC»).

Если брать те же примеры из документации Apple, то у них контроллеры очень разные. Толстые и тонкие, на любой вкус. Поэтому в статью, помимо обзора нескольких паттернов для чайников, я добавил призыв думать своей головой. Может быть, его надо подкрепить какими-то другими примерами — если есть идеи, пишите.

P.S. Просьба не кидать тапками, но вот читаю Фаулера, не вижу ничего криминального в MVP.
Задумка-то хорошая
To approach MVP I find it helpful to think about a significant mismatch between two strands of UI thinking. On the one hand is the Forms and Controller architecture which was mainstream approach to UI design, on the other is MVC and its derivatives. The Forms and Controls model provides a design that is easy to understand and makes a good separation between reusable widgets and application specific code. What it lacks, and MVC has so strongly, is Separated Presentation and indeed the context of programming using a Domain Model. I see MVP as a step towards uniting these streams, trying to take the best from each.
Вы меня не поняли. MVP это не плохо. Плохо называть вещи чужими именами.
Раз уж вам нравится Фаулер то вот:
I've lost count of the times I've seen something described as MVC which turned out to be nothing like it.
Вы не совсем понимаете видимо специфику большинства приложений под иОСь — большинство приложений для этой платформы суть всякие околокомерческие, суть в кратце такова их:
Выкачиваеш с серва ексемельку/жисон->конвертируеш в модели данных->наследник UIViewController принимает действия пользователя и кидает на вьюхи те или иные модели данных, для этой попсы Модель/Вид/Контроллер подходит как нельзя лучше.
Это сарказм или я неправильно понял?
Модель не знает вообще о View и не должна ничего никому передавать. Контроллер смотрит в модель и в соответствии с этим меняет вью.
Вы про MVC видно знаете только из шаловливых документов Apple где полоная #уйня написана. Почитайте про настоящий MVC. Хоть на вики. А ещё почитайте про MVP. Озарение снизойдет

И не смотрите что у вашего комента +3 а у моего минус сколькототам. Это не потому что вы правы. А потому что мы в посте про яблочную шнягу и тут ваши товарищи у которых программировнаие началось с клепания форм для ios которые тоже понятия не имеют об архитектурных паттернах для GUI.
А есть более конструктивные предложения? :)

Да, есть толпа, которая называет чёрное белым MVP — MVC. И Stanford University туда же. На Stackoverflow есть заплюсованный ответ, что MVP — это разновидность MVC. Смотря что считать контроллером.

Вопрос в том: мы с вами что можем сделать? Ну, я дополню пост инфой из данного обсуждения. И всё? Если да, то куда мы против Стэнфорда.
Вот это хорошо, что вы подчеркнули разделение логики реагирования и бизнес-логики. А то я как 10 лет назад придумал, как потом выяснилось, «бесконтроллерную» мини-библиотеку, так потом тоже никогда не мог понять, зачем контроллер вообще нужен.

Правда, мой опыт относится к Java…
Смущения лично у меня вызвали следующие моменты

1. (self.delegate == nil) — зачем? Не проще ли написать if (!self.delegate)

2. Контрол с горизонтальными картинками по моему мнению лучше реализовать через UICollectionView (или через PSTCollectionView если версия 5) — не надо будет ломать мозг с математикой.
А конструктор с четырьмя параметрами вас не смутил?)
А если бы у модели было 12 свойств? Конструктор и 12 параметров?
группировать параметры в объекты — очевидно.
либо дальнейшая декомпозиция, как писали выше, либо делать свойства мутабельными, либо писать builder.
Я понимаю что делать в таких ситуациях, спасибо, капитаны.
Я веду к тому, что составлять такие конструкторы не очень ок. Что вы будете делать если еще одно свойство будет добавлено или удалено?
В общем понятно, Вандерлих и иже с ним вам в помощь.
А можно поподробнее, почему не ок?

Если речь только о скорости рефакторинга, то щас же по нажатию одной кнопочки всё делается.
Пример
Тут скорее проблема в _необходимости_ этих полей. Не всегда они являются обязательными, и получаются всевозможные initWith nil nil nil @"Fuu".
Ярчайший пример, имхо, это AutoLayout с его NSLayoutAttributeNotAnAttribute.
Вандерлиха не читал никогда, не понимаю о чем Вы.
Оригинал статьи как-раз из блога этого самого вандерлиха.
Я бы забил на подобные выпады )
1) я лично всегда так пишу, более понятно и очевидно
По-моему это надо читать до полного просветления.
А из книжек про паттерны что-нить? Чтобы одним выстрелом вообще всех зайцев?
Дополнил пост разделом «Что почитать?»

Одним выстрелом не получится! У каждого своя голова. Сам Страуструп говорил, что он знает ООП «на троечку» (цитату сейчас не могу найти, но смысл такой).
в «фасаде» в LibraryAPI.h можно не импорить Album.h, более того, даже нужно не импортить, а заменить на
@class Album;
, так как никакие внутренности класса Альбом использоваться не будут и просто сказать, что такой класс существует — достаточно
Sign up to leave a comment.

Articles