Pull to refresh

Comments 18

Неожиданно странная для Право.ру статья. Мария, не поверю, что Никита и его команда только сейчас узнали о паттернах.
Упоминания паттернов ради упоминания паттернов? Да ещё и не совсем верное.

потому что разработчики использовали шаблоны проектирования.

Многие разработчики используют шаблоны проектирования. Но это не позволяет заменять одни решения на другие. Возможно речь об интерфейсах?

Его назначение в том, что он инкапсулирет в себе логику преобразования данных вообще с любого протокола, который задействован в веб-сервисе. А значит имеется возможность перейти на экономичный Protobuf, причем практически так же безболезненно.

Это не назначение паттерна прокси. Это всего лишь следствие его применения.

Что за странные ссылки на непонятные файлообменники с сиськами? Почему нельзя было поставить ссылку на форк (неважно в кодегугле или гитхабе)? Если лицензия не позволяет, можно было бы выложить патч?
>> Многие разработчики используют шаблоны проектирования. Но это не позволяет заменять одни решения на другие. Возможно речь об интерфейсах?

Речь о бизнеслогике. Если нужно кешировать не на день, а до удачного получения соединения с интернет в нескольких логически связанных отделениях, то пишется потомок одной из ветки классов ответственного за кеширование, далее он объявляется ведущим в выборке данных одного или нескольких логических отделений. Занимает это пару строчек кода, а работает на данном принципе кеширования все приложение.

>> Это не назначение паттерна прокси. Это всего лишь следствие его применения.

Согласен, у паттернов нет назначений, но мы легко находим им применение
Внедрение новой библиотеки JSONKit взамен старой SBJSON не составила никакого труда, потому что разработчики использовали шаблоны проектирования.

Многие разработчики используют шаблоны проектирования. Но это не позволяет заменять одни решения на другие. Возможно речь об интерфейсах?

Речь о бизнеслогике.

Причём тут бизнес-логика?
Извините, конечно! В данном контесте речь конечно не о бизнеслогике, а о решении. Тоесть один парсер — одно решение, другой парсер или протокол — это другое решение. В данном контексте как раз таки паттерны позволили
«Но это не позволяет заменять одни решения на другие. Возможно речь об интерфейсах?»
так что еще как позволяет!
Прошу прощения за фамильярность, Сергей, но кажется вы уже и сами запутались о чём вообще статья.
ну так хабр, на то и символика, давайте распутываться)
Это не назначение паттерна прокси.

Согласен, у паттернов нет назначений, но мы легко находим им применение


Ок, Серёг, не будем обращать внимание на то, что ты согласился с утверждением, которое твой собеседник не высказывал. Но говорить, что у паттернов нет назначений — это уже за гранью добра и зла. Я просто не могу молчать.

Большая часть используемых нами паттернов описаны в каталоге GoF «Паттерны проектирования» (иллюстрация к этому каталогу у нас в кабинете висит). Согласно этому каталогу, описание паттерна содержит следующую информацию: название и классификация, назначение, мотивация, применимость, структура, участники, отношения, результат, реализация и тп.
Так вот, назначение Proxy — «Является суррогатом другого объекта и контролирует доступ к нему». (Паттерны проектирования, стр 203, Питер, 2010)
Кто-то очень любит цепляться к словам.
Да, в этой книге очень хороший перевод, трудно не согласиться
в статье 1% практической ценности взятой из википедии и 99% пиара. какова цель статьи?
Цель наша, да, пиар — какие мы крутые разработчики, создаем крутой продукт.
Поделились опытом, тестами и исходниками.
А вы тут какую цель преследуете? Можит мы вам не подходим по интересам?
мы использовали паттерн проектирования «Посредник» (Proxy)

ну вообще-то посредник — это Mediator. Они даже к разным группам относятся: медиатор — шаблон поведения, а прокси — структурный
Согласен: в данной задаче использовался Заместитель для того чтобы изолировать реализацию парсинга. А вот медиатор кстати скорее в задаче кеширования, для того чтобы подменить данные, загружаеммые с сервера локальными. Композитор используется на стыке взаимодействия поставщика данных и кешером с одним и тем же парсером/сериализатором.
Объясните каким образом использование zip архива предотвращает удаление данных из кеша? Ерунду какую то написали, если сохраняете в Documents, так и пишите, причем тут архивы?
Да, в Documents. В сохранности остаются файлы только там. Но если закешированные файлы вы попытаетесь сохранить сразу туда, то из Apple Store вероятней всего придет письмо, о том что не следует держать такое обилие файлов, вероятнее всего вам необходимо перевести все в cashes. Вот тут и приходит на выручку zip
Это Вас никак не выручает. iOS Data Storage Guidelines говорит, что в Documents нужно хранить только user-generated контент. Все что можно восстановить по сети нужно кидать в Caches. То, что Вы не получили реджект за zip в Documents скорее везение, чем правильное решение. Более того, в Apple придумали специальный аттрибут для файлов, который позволяет безопасно хранить их в Documents. Этот аттрибут запрещает синхронизацию файлов через iCloud, из-за которого собственно и нельзя хранить скачиваемый контент в Documents.
так программно иммено user и создает zip, так что проверку проходит легко. Атрибут запрета мы не выставляем, дабы можно было переносить документы на другое устройство
каким образом user создает zip? он вносит правки в ваши материалы? или все авторство со стороны юзера сводится к выбору какие статьи скачать?
ему предлагается произвести резервное копирование, он вправе отказаться.
Sign up to leave a comment.