Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 50
Вот это да. Огромное спасибо! Это просто титанический труд!
Как-раз собирался прочесть у Рея, а тут вы подоспели с переводом!
P.S. ай-я-яй, искали разработчиков, и не написали ;) в моей команде у всех отличные знания паттернов :)
Как-раз собирался прочесть у Рея, а тут вы подоспели с переводом!
P.S. ай-я-яй, искали разработчиков, и не написали ;) в моей команде у всех отличные знания паттернов :)
спасибо за перевод!
интересно. я всегда считал, что GoF родился в первую очередь из Smalltalk практики авторов, а Objective C — попытка обеспечить объектное программирование для C, натянув идеи Smalltalk-а, вместо идей Страуструпа. Но сложная судьба инструмента, видимо сказалась.
Понятно, что плюсы учат по Страуструпу и «банде четырёх», а Objective C — больше по туториалам и Stack Overflow
интересно. я всегда считал, что GoF родился в первую очередь из Smalltalk практики авторов, а Objective C — попытка обеспечить объектное программирование для C, натянув идеи Smalltalk-а, вместо идей Страуструпа. Но сложная судьба инструмента, видимо сказалась.
«2. Забудьте тот ужас, который вы видели на developer.apple.com! Да-да, те примеры, где ViewController'ы играют две-три роли одновременно. — Прим. пер.»
Собственно, этот ужас писали как раз инженеры Apple, те самые, кто занимается и выпуском самих iOS/Mac OS X. Можно сколько угодно тыкать их носом в их корявый код — но он работает и приносит прибыль, не снящуюся никакому коучу (мы же говорим о коммерческом коде, не так ли?).
Я проходил в жизни достаточное количество успешных собеседований, чтобы понять одну простую вещь: идеала нет и быть не может. А меньше всего идеала было там, где на собеседовании тебя закидывали вопросами про паттерны и круглые крышки люков (насчет последнего, кстати, уже не то, чтобы поумнели резко, но сам великий Гугл сказал, что это не работает и вдруг в одночасье такие вопросы стали немодными). И ты такой счастливый, потому что думаешь, что кончился наконец этот бардак в голове и в репозитории и ты, наконец, попал куда нужно, тут сидят Правильные Люди и пишут Правильный Код. Щас же. Говнокод на говнокоде, патч на патче, и особенно у тех самых техлидирующих, кто с сожалением смотрел с той стороны стола переговорки HR отдела на тебя, мычащего незаученно о том, Как Действительно Надо Писать Приложения. Исхода нет.
Одни пишут код, другие учат писать код.
Спасибо за перевод и потраченное время. Такие статьи — как путеводная звезда для нас всех, они позволяют верить во что-то большее. Где-то, где-то есть такие компании, я все еще верю.
Собственно, этот ужас писали как раз инженеры Apple, те самые, кто занимается и выпуском самих iOS/Mac OS X. Можно сколько угодно тыкать их носом в их корявый код — но он работает и приносит прибыль, не снящуюся никакому коучу (мы же говорим о коммерческом коде, не так ли?).
Я проходил в жизни достаточное количество успешных собеседований, чтобы понять одну простую вещь: идеала нет и быть не может. А меньше всего идеала было там, где на собеседовании тебя закидывали вопросами про паттерны и круглые крышки люков (насчет последнего, кстати, уже не то, чтобы поумнели резко, но сам великий Гугл сказал, что это не работает и вдруг в одночасье такие вопросы стали немодными). И ты такой счастливый, потому что думаешь, что кончился наконец этот бардак в голове и в репозитории и ты, наконец, попал куда нужно, тут сидят Правильные Люди и пишут Правильный Код. Щас же. Говнокод на говнокоде, патч на патче, и особенно у тех самых техлидирующих, кто с сожалением смотрел с той стороны стола переговорки HR отдела на тебя, мычащего незаученно о том, Как Действительно Надо Писать Приложения. Исхода нет.
Одни пишут код, другие учат писать код.
Спасибо за перевод и потраченное время. Такие статьи — как путеводная звезда для нас всех, они позволяют верить во что-то большее. Где-то, где-то есть такие компании, я все еще верю.
этот ужас писали как раз инженеры AppleИли специально нанятая команда индусов. :) Я больше склоняюсь к такому варианту.
Инженеров
а почему не проверили(albumIndex >= 0)? Автор туториала об этом не подумал, а создатели классаNSArrayподумали
это все из-за суеты же?
но я помню, как ты сам мне рассказывал про толкового менеджера, настаивавшего на правильном написании кода («чтобы девочка 1С-ца могла понять) и насколько приятнее и легче жить, когда сдаешь именно такой проект, а не „наваленный“
но я помню, как ты сам мне рассказывал про толкового менеджера, настаивавшего на правильном написании кода («чтобы девочка 1С-ца могла понять) и насколько приятнее и легче жить, когда сдаешь именно такой проект, а не „наваленный“
Отличный и доходчивый перевод! Огромное спасибо!
А я бы вот эту книгу рекомендовал. Использую как справочник.
Все не читал, но возникло ощущение что еще немного и получится MVVM.
Привет! Я тебя часто вижу в ReactiveCocoa на гитхабе. MVVM пока сложно реализовывать для большинства iOS разработчиков, выращенных на туториалах, все упирается в bindings и непонимание того что ViewController это View Layer, а уж когда они видят код RAC, то и вовсе руки опускаются. Видел этот тикет? )) github.com/ReactiveCocoa/ReactiveCocoa/issues/393
В защиту инженеров Apple скажу, что большая часть примеров со спагетти-контроллерами обычно демонстрирует какую-то одну конкретную технологию/фреймворк/класс, а не является примером «как вообще надо писать код»
Можно добавить, что если уж кидать камень в огород кода на известном портале, то не стоит приводить в пример то, что приведено. С магическими числами и строками по всему коду, макросами вместо типизированых констант, стилистическими неоднородностями или моментами, идущими вразрез с общепринятыми соглашениями.
Давно ждал такую статью. Книжка четырех, с их натянутыми примерами на C-smallTalk очень трудно осилить начинающему спецу, имхо.
Огромное спасибо!
Огромное спасибо!
По паттернам лучше эту почитать: Head First Design Patterns, ее даже сами ребята и GOF'a рекомендуют.
Вступление к переводу очень хорошее, но когда увидел что это вандерлих, то стало как-то «странно».
ИМХО, все эти ребята как раз и являются одним из источников зла в ObjC dev мире.
Читабельность из кода — это нечто высокое, величественное.
ИМХО, все эти ребята как раз и являются одним из источников зла в ObjC dev мире.
Читабельность из кода — это нечто высокое, величественное.
Вы схему для MVC похоже сами нарисовали. И разделение обязанностей видно тоже во сне увидели.
1. Контроллер ничерта не знает о конкретной View, чтобы они были элементарно заменяемы без смены контроллера.
2. Модель никогда не уведомляет контроллер ни о каких своих изменениях. Она уведомляет непосредственно View.
В MVC главный принцип что всё строится вокруг модели. И View и Controller легко заменяемы. View — чтобы сменить представление (консоль, html, вывод в сокет), и контроллер — чтобы сменить логику реагирования (но не бизнес логику).
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.
Про детей, боюсь, поздно думать, потому что в Стэнфорде уже 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.
Вы не совсем понимаете видимо специфику большинства приложений под иОСь — большинство приложений для этой платформы суть всякие околокомерческие, суть в кратце такова их:
Выкачиваеш с серва ексемельку/жисон->конвертируеш в модели данных->наследник UIViewController принимает действия пользователя и кидает на вьюхи те или иные модели данных, для этой попсы Модель/Вид/Контроллер подходит как нельзя лучше.
Выкачиваеш с серва ексемельку/жисон->конвертируеш в модели данных->наследник UIViewController принимает действия пользователя и кидает на вьюхи те или иные модели данных, для этой попсы Модель/Вид/Контроллер подходит как нельзя лучше.
Это сарказм или я неправильно понял?
Модель не знает вообще о View и не должна ничего никому передавать. Контроллер смотрит в модель и в соответствии с этим меняет вью.
Модель не знает вообще о View и не должна ничего никому передавать. Контроллер смотрит в модель и в соответствии с этим меняет вью.
Вы про MVC видно знаете только из шаловливых документов Apple где полоная #уйня написана. Почитайте про настоящий MVC. Хоть на вики. А ещё почитайте про MVP. Озарение снизойдет
И не смотрите что у вашего комента +3 а у моего минус сколькототам. Это не потому что вы правы. А потому что мы в посте про яблочную шнягу и тут ваши товарищи у которых программировнаие началось с клепания форм для ios которые тоже понятия не имеют об архитектурных паттернах для GUI.
И не смотрите что у вашего комента +3 а у моего минус сколькототам. Это не потому что вы правы. А потому что мы в посте про яблочную шнягу и тут ваши товарищи у которых программировнаие началось с клепания форм для ios которые тоже понятия не имеют об архитектурных паттернах для GUI.
А есть более конструктивные предложения? :)
Да, есть толпа, которая называетчёрное белым MVP — MVC. И Stanford University туда же. На Stackoverflow есть заплюсованный ответ, что MVP — это разновидность MVC. Смотря что считать контроллером.
Вопрос в том: мы с вами что можем сделать? Ну, я дополню пост инфой из данного обсуждения. И всё? Если да, то куда мы против Стэнфорда.
Да, есть толпа, которая называет
Вопрос в том: мы с вами что можем сделать? Ну, я дополню пост инфой из данного обсуждения. И всё? Если да, то куда мы против Стэнфорда.
Вот это хорошо, что вы подчеркнули разделение логики реагирования и бизнес-логики. А то я как 10 лет назад придумал, как потом выяснилось, «бесконтроллерную» мини-библиотеку, так потом тоже никогда не мог понять, зачем контроллер вообще нужен.
Правда, мой опыт относится к Java…
Правда, мой опыт относится к Java…
Смущения лично у меня вызвали следующие моменты
1. (self.delegate == nil) — зачем? Не проще ли написать if (!self.delegate)
2. Контрол с горизонтальными картинками по моему мнению лучше реализовать через UICollectionView (или через PSTCollectionView если версия 5) — не надо будет ломать мозг с математикой.
1. (self.delegate == nil) — зачем? Не проще ли написать if (!self.delegate)
2. Контрол с горизонтальными картинками по моему мнению лучше реализовать через UICollectionView (или через PSTCollectionView если версия 5) — не надо будет ломать мозг с математикой.
А конструктор с четырьмя параметрами вас не смутил?)
А что собственно делать, если нужно столько параметров?
А если бы у модели было 12 свойств? Конструктор и 12 параметров?
группировать параметры в объекты — очевидно.
либо дальнейшая декомпозиция, как писали выше, либо делать свойства мутабельными, либо писать builder.
Я понимаю что делать в таких ситуациях, спасибо, капитаны.
Я веду к тому, что составлять такие конструкторы не очень ок. Что вы будете делать если еще одно свойство будет добавлено или удалено?
В общем понятно, Вандерлих и иже с ним вам в помощь.
Я веду к тому, что составлять такие конструкторы не очень ок. Что вы будете делать если еще одно свойство будет добавлено или удалено?
В общем понятно, Вандерлих и иже с ним вам в помощь.
1) я лично всегда так пишу, более понятно и очевидно
По-моему это надо читать до полного просветления.
А из книжек про паттерны что-нить? Чтобы одним выстрелом вообще всех зайцев?
А из книжек про паттерны что-нить? Чтобы одним выстрелом вообще всех зайцев?
в «фасаде» в LibraryAPI.h можно не импорить Album.h, более того, даже нужно не импортить, а заменить на
@class Album;
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Паттерны ООП в примерах для iOS