Есть так называемая «38-я форма», а если быть точнее форма 38001, заполнив которую, можно запретить регистрацию юр. лиц, без личного присутствия
Перерыл половину интернета, форма 38001 — это «возражение» против совершаемых действий. Как его заполнять, если, тьфу х3, меня эта проблема с мошенниками еще не коснулась? Как запретить вообще любые действия без моего присутствия? Где об этом посмотреть, как заполнять заявление? Весь интернет пестрит фразами «заполните — и будете защищены» (но как заполнять — никто не объясняет), а юридические сайты отсылают к законам, где лишь набор слов, понятный разве что юристам. Как заполнить человеку (ИП/физик), который просто не хочет, чтобы без его присутствия что-то делали?
Во-первых, в таком случае они должны быть вместе с публичными свойствами, а они от них унесены неизвестно куда.
Не должны. Лучше иметь отдельный участок-секцию кода, где идут только свойства, упорядоченные по порядку паблик-readonly-приват. А потом уже идет конструктор, и лишь потом — публичные методы. Смешивать код по принципу модификатора доступа — не самая удачная идея, потому что их мало (часто используемых — всего два). Так ваш код разобьется всего на две огромных секции внутри файла. А разделение по смысловым элементам (typealias'ы, свойства, приватные свойства, конструктор/деструктор, методы, приватные методы, реализация протоколов) дает куда больше секций в коде, а значит, и повышает простоту восприятия его структуры. Аналогия: что проще, книга на тему «Программирование» из двух огромных общих глав, или из двадцати, но более конкретных?
а почему, собственно, то, как класс выглядит «снаружи», должно влиять на то, как он расположен в файле?
Потому что часто бывает задача изучить неизвестный класс, его функционал, и сделать это побыстрее, не отсматривая все тело файла. В первую очередь аккуратная «внешность» (создаваемая правильным порядком элементов) будет полезна вам, когда вы забудете, как устроен класс, в большом проекте. Во-вторых, она полезна новым людям, которые придут на проект и будут должны как можно быстрее изучить его. В большинстве случаев, в крупных проектах не нужно вникать во «внутренности» класса, потому что он и так нормально работает. Нужно лишь понять, какие возможности он предоставляет для пользования (те самые публичные элементы). И если все расположено правильно, то, увидев private, вы поймете, что публичные элементы уже закончились, дальше можно не смотреть, если нет задачи перетряхнуть внутренности. Если же это не так — то придется отсматривать весь файл.
И да, есть вариант «отсматривать автоматически создаваемое подобие хедера файла» через спец. кнопку в Xcode, но это довольно тормозная штука, и поэтому, лично на мой взгляд, неудобная.
Почему так, а не «публичный метод и используемые им приватные методы»?
Отвечу со своей колокольни. В варианте «сначала паблик, потом приват» при отсмотре файла вы точно знаете, что если видите приватный метод, то все, публичные — закончились. А если делать вперемешку, как вы предложили, то вы никогда не узнаете, где и когда в файле заканчиваются публичные методы. А учитывая, что свифтовый код пишется в одном файле (без хедеров, отделяющих публичную часть), то при изучении чужого кода на предмет «что там где находится, что умеет класс, какие свойства и методы отдает наружу и т.д.» вам будет на порядок сложнее разобрать каждый незнакомый вам класс. Ваш подход удобен лишь «для себя самого», пока на проекте все известно, и нет людей, не знакомых с кодом. А еще нет авралов.
Поддерживаю. Сам стараюсь в проектах, где работаю, добровольно-принудительно вводить такой же порядок. Очень помогает преобразить код из состояния «свалка» в состояние «книга».
В двух словах: «Альтернативная IDE». Написана иначе, на другом языке, обладает тонной интересных плюшек (не всем они нужны, но есть — и хорошо), по производительности и багам — где-то лучше Xcode, где-то AppCode. Я пока так и не смог перейти на AppCode, в основном, из-за тормозов с автокомплитом и «java-style» внешности и отклика управления. Не знаю, как объяснить последний свой пункт, но вот как-то прям чувствуется, это приложение работает иначе, чем привык в Xcode, скролл не такой плавный, выравнивание элементов другое (по отступам слева), и т.д. Вкусовщина.
Подтверждаю, у нового VW Polo (купили месяц назад) эта шняга в подстаканнике есть. Чуть не выдрали по первости, думали, стаканчик какой, потом дилера спросили, сказали «не выдирайте, она там намертво, и это динамик глонасса».
Про пункт 1 не соглашусь, как и Funbit. Все действия по шифрованию передаваемых данных будут «лишними» только при условии 100% гарантии, что канал передачи данных не взломан. А если MITM? А если подмена сертификатов? В случае отсутствия дополнительных ступеней защиты, после взлома канала передачи данных все данные будут скомпрометированы. А вот если данные зашифрованы, то вскрытие канала взломщику не то чтобы прям сильно поможет. Безопасности много не бывает, чем больше замков на двери — тем меньше шанс, что ее вскроют за разумное время и деньги.
Можно. А все, что сделал автор в либе, можно сделать и без этой либы. Но я говорю конкретно о ней и ее фишках, а не о других способах выполнить задачу. Другие способы есть всегда.
Перечитал статью, подумал вот о чем. Мне сильно не хватает в оберточных либах возможности делать dependent-запросы. То есть, зачастую нужно, чтобы отработал вот этот запрос, потом вот этот, и еще вот этот, и только тогда считать группу запросов выполненной. Например, если каждый из них отработал без ошибок, или только парочка из трех запрошенных, допустим. Сейчас решаю это тупой вложенностью (один запрос — onSuccess — второй запрос — onSuccess, и т.д.), что не совсем верно, так как запросы не одновременно идут, но мне хватает. Есть ли планы ввести что-то подобное в либу?
Еще похожая тема — chained-запросы, при котором один запрос идет строго после другого, цепочкой, а результатом является опять результат выполнения группы цепных запросов.
И еще одно — отмена запросов. Юзер перешел на другой экран, ткнул отмену или что-то такое — надо иметь возможность обрубить левые запросы, которые более не нужны.
Неплохой подход. Наверное, каждый что-то подобное пилит в каждом своем проекте)) У меня тоже что-то такое встроено самописное поверх Аламофаера. Но возьму на заметку, спасибо. Если будете поддерживать либу, то отлично.
P.S. Где-то в разметке статьи забыли <i* тег закрыть, или закрыли не там, где стоило) Пофиксите пж, а то весь подвал в курсиве)
Код менять всегда придется, само собой ничего не произойдет. Однако одно дело — править код в единственном месте (в координаторе, максимум — в нем и плюс еще в рутовом, который может удерживать на него ссылку), а совсем другое — во всех местах, связанных с данным контроллером (когда у вас 5 экранов реализуют один и тот же код вызова контроллера — править придется 5 мест).
Это всегда две стороны одной медали. Чем больше разделение ответственности — тем сложнее структура системы, но тем проще ее модификация, сопровождение и тестирование (при условии, что человек разобрался в архитектуре, конечно же, и реализует ее корректно). И наоборот, чем меньше разделение — тем проще ориентироваться в структуре проекта, тем меньше требуемая квалификация (пока багов нет и контроллеры не разрослись выше 1000 строк), однако тем тяжелее и трудозатратнее становится расширять систему. Совместить «лучшее из лучших» не получится, во всяком случае, на данный момент ничего не придумано. Предложенный подход с координаторами — нечто среднее по сложности между MVC/MVP и VIPER, некий компромисс, кроме того, ее сложность можно подстроить под проект, это уже зависит от навыка архитектора. Лично мне подход нравится.
На мой взгляд, «серебряной пули» в виде идеальной архитектуры нет и быть не может, под каждую задачу есть свое подходящее решение. Реализовывать тяжеловесный VIPER в двухэкранном приложении — дико избыточная и нерентабельная затея, но и писать огромное банковское приложение на базе традиционного MVC — тоже так себе идея. Если утрировать, шуруп можно и молотком забить, но лучше все же воспользоваться отверткой.
Предложите ваш вариант реализации в отдельной статье на хабре. Возможно, ваш подход действительно окажется удобнее, так почему бы не показать ваши навыки и не поделиться знаниями через собственную полезную статью?
Ой как много воды о том, что такое инкапсуляция (что аутлеты не должны торчать наружу)… И, кстати говоря, это зависит от применяемой архитектуры, иногда нужно как раз наоборот. Но если «по-простому» — то да, в большинстве случаев аутлеты, если уж вы их используете, делаем приватными, чтобы извне был доступен минимум информации. Все, вся статья в двух предложениях.
Убрали косяк в первом вопросе, смотрю? А они еще остались, и это я еще андроид не смотрел, ибо не моя стихия. Но неважно. Потестил я тут слегка ваш тест, обнаружил, что можно легко накрутить результат, если просто проходить тест раз за разом, даже браузеры не обязательно переключать. Наверное, при простейшей реализации добиться уникальности результатов слишком сложно, спорить не буду, но сам факт — «заруба» нерелевантная, не только из-за качества тестов, а еще и из-за отсутствия ограничителя на неограниченное перепрохождение.
Поддерживаю. Underground state отобразился как неверный вариант — ну крайне любопытно, где ж там такой. За 7 лет работы в iOS не заметил ничего похожего. Да и другие вопросы к тесту есть. Слабо составлено, если это пропустили организаторы как релевантный опрос — то там реально делать совершенно нечего, раз даже на уровне ревью и организации мероприятия так относятся к подаче информации.
Спасибо за статью. Как вариант — посмотрите библиотеку R.swift на гитхабе. Если верно понял, она решит большую часть ваших задач, и еще с более изящным кодом на выходе, а также с минимальными настройками и элементарной интеграцией (однострочный скрипт в настройках проекта и копипаста сгенерированного файла один раз в сам проект). Я сейчас ее пользую, и очень доволен, плюсы все те же, что вы перечислили (плюс легкая настройка + поддержка, кроме локализации и изображений, еще и шрифтов, XIB'ов и цветов). Из минусов — тоже не умеет отсекать неиспользуемые ресурсы.
Перерыл половину интернета, форма 38001 — это «возражение» против совершаемых действий. Как его заполнять, если, тьфу х3, меня эта проблема с мошенниками еще не коснулась? Как запретить вообще любые действия без моего присутствия? Где об этом посмотреть, как заполнять заявление? Весь интернет пестрит фразами «заполните — и будете защищены» (но как заполнять — никто не объясняет), а юридические сайты отсылают к законам, где лишь набор слов, понятный разве что юристам. Как заполнить человеку (ИП/физик), который просто не хочет, чтобы без его присутствия что-то делали?
Не должны. Лучше иметь отдельный участок-секцию кода, где идут только свойства, упорядоченные по порядку паблик-readonly-приват. А потом уже идет конструктор, и лишь потом — публичные методы. Смешивать код по принципу модификатора доступа — не самая удачная идея, потому что их мало (часто используемых — всего два). Так ваш код разобьется всего на две огромных секции внутри файла. А разделение по смысловым элементам (typealias'ы, свойства, приватные свойства, конструктор/деструктор, методы, приватные методы, реализация протоколов) дает куда больше секций в коде, а значит, и повышает простоту восприятия его структуры. Аналогия: что проще, книга на тему «Программирование» из двух огромных общих глав, или из двадцати, но более конкретных?
Потому что часто бывает задача изучить неизвестный класс, его функционал, и сделать это побыстрее, не отсматривая все тело файла. В первую очередь аккуратная «внешность» (создаваемая правильным порядком элементов) будет полезна вам, когда вы забудете, как устроен класс, в большом проекте. Во-вторых, она полезна новым людям, которые придут на проект и будут должны как можно быстрее изучить его. В большинстве случаев, в крупных проектах не нужно вникать во «внутренности» класса, потому что он и так нормально работает. Нужно лишь понять, какие возможности он предоставляет для пользования (те самые публичные элементы). И если все расположено правильно, то, увидев private, вы поймете, что публичные элементы уже закончились, дальше можно не смотреть, если нет задачи перетряхнуть внутренности. Если же это не так — то придется отсматривать весь файл.
И да, есть вариант «отсматривать автоматически создаваемое подобие хедера файла» через спец. кнопку в Xcode, но это довольно тормозная штука, и поэтому, лично на мой взгляд, неудобная.
Отвечу со своей колокольни. В варианте «сначала паблик, потом приват» при отсмотре файла вы точно знаете, что если видите приватный метод, то все, публичные — закончились. А если делать вперемешку, как вы предложили, то вы никогда не узнаете, где и когда в файле заканчиваются публичные методы. А учитывая, что свифтовый код пишется в одном файле (без хедеров, отделяющих публичную часть), то при изучении чужого кода на предмет «что там где находится, что умеет класс, какие свойства и методы отдает наружу и т.д.» вам будет на порядок сложнее разобрать каждый незнакомый вам класс. Ваш подход удобен лишь «для себя самого», пока на проекте все известно, и нет людей, не знакомых с кодом. А еще нет авралов.
Еще похожая тема — chained-запросы, при котором один запрос идет строго после другого, цепочкой, а результатом является опять результат выполнения группы цепных запросов.
И еще одно — отмена запросов. Юзер перешел на другой экран, ткнул отмену или что-то такое — надо иметь возможность обрубить левые запросы, которые более не нужны.
С этими плюшками будет прям огонь.
P.S. Где-то в разметке статьи забыли <i* тег закрыть, или закрыли не там, где стоило) Пофиксите пж, а то весь подвал в курсиве)
Это всегда две стороны одной медали. Чем больше разделение ответственности — тем сложнее структура системы, но тем проще ее модификация, сопровождение и тестирование (при условии, что человек разобрался в архитектуре, конечно же, и реализует ее корректно). И наоборот, чем меньше разделение — тем проще ориентироваться в структуре проекта, тем меньше требуемая квалификация (пока багов нет и контроллеры не разрослись выше 1000 строк), однако тем тяжелее и трудозатратнее становится расширять систему. Совместить «лучшее из лучших» не получится, во всяком случае, на данный момент ничего не придумано. Предложенный подход с координаторами — нечто среднее по сложности между MVC/MVP и VIPER, некий компромисс, кроме того, ее сложность можно подстроить под проект, это уже зависит от навыка архитектора. Лично мне подход нравится.
На мой взгляд, «серебряной пули» в виде идеальной архитектуры нет и быть не может, под каждую задачу есть свое подходящее решение. Реализовывать тяжеловесный VIPER в двухэкранном приложении — дико избыточная и нерентабельная затея, но и писать огромное банковское приложение на базе традиционного MVC — тоже так себе идея. Если утрировать, шуруп можно и молотком забить, но лучше все же воспользоваться отверткой.