Паттерн Visitor позволяет сделать универсальный обход структуры. Он становится полезен, когда мы имеем не один объект из семейства, а структуру из множества объектов. Например, внутри треугольника могут лежать квадраты, в которых есть другие треугольники. А у вас Visitor знает только то, как работать с одним треугольником и с одним квадратом. То, как они друг в друга входят, посетитель не знает. Как только Visitor обработал одну фигуру, управление передается в метод accept, а там уже наш Visitor получит для обработки следующую фигуру.
Основная идея данного приема — избавиться от god-метода со свитчом:
switch (figure.type) {
case Triangle:
visitTriangle(figure);
break;
case Circle:
visitCircle(figure);
break;
case Rectangle(figure);
visitRectangle(figure);
break;
}
Если figure — простая фигура, то этот switch можно расширять до бесконечности и особых проблем не заметить. Но если figure состоит из других фигур, то внутри методов visitRectangle, visitCircle, visitTriangle придется сделать отдельные свитчи, и вот тут-то уже возникают реальные сложности, когда можно в 3 объектах запутаться. И тогда на помощь приходит Visitor.
Насчет возврата множественных значений — сущая правда. Есть еще альтернатива — передать в качестве параметров коллекцию, в которую запихнуть результат.
Есть довольно много классов, отвечающих за сериализацию, которые отправляют результат в Writer. Если пользователь хочет получить строку, то он передает им StringWriter. Так что можно сказать, что он не удобнее, а просто в некоторых ситуациях не имеет альтернативы.
Насколько я помню, StringBuffer спрятан внутри StringWriter. В нем не сказано, что он устаревший или неэффективный. А интерфейс у него удобный. Вот все и пользуются.
Язык точно этого не должен. Это для багтрекера желательно уметь использовать особенности языка. Я не говорю, что это обязательно, но при выборе языка для нового проекта я на это посмотрю
В некоторых случаях это может быть очень важно. Например, есть такая штука как SSIS-пакеты, в них практически невозможно изменения сматчить с дефектами, потому что там файлы почти бинарные. И разумеется, разработчики, когда их начинали писать, читали интересные статьи о том, какая это классная штука.
В части багтрекинга мне было бы достаточно, если бы в багтрекере была подсветка синаксиса, а в IDE работали бы ссылки из комментариев вида // Also see Issue 166;.
По-моему, после нескольких лет серьезной разработки становится все равно, на каком языке писать. Если у меня долгоиграющий проект, то я буду его продолжать на том языке, на котором написана большая часть кода, хоть на дельфи.
Если у меня новый проект, то я буду смотреть на:
наличие специалистов в команде
лицензионные ограничения
требования к рабочему окружению
среду разработки
возможности стандартной библиотеки
наличие сторонних библиотек
поддержку параллелизма
перспективу развития
интеграцию с инструментами документирования, багтрекинга, управления ЖЦ, Continuos Integration и т. п.
и где-то там, пунктов на 10 ниже, будет синтаксис.
Поэтому описание особенностей синтаксиса не отвечает на вопрос из заголовка: «Почему следует полностью переходить на Kotlin».
Можно еще добавить обычные почтовые клиенты. Получаешь письмецо, а там…
Не очень понял про кэширующий сервер на Windows. Как вы представляете атаку на него? Или вы имеете в виду случай, когда NTFS-раздел примонтирован к каталогу?
Точно. Кроме браузеров. Есть же и другие программы, которые по ссылкам умеют лазить, в том числе и производства Микрософт. Что у нас есть? Скайп какой-нибудь, антивирусы. Например, что-нибудь такое в архиве прислать, чтобы Windows Defender поискал хитрый путь. Есть что поисследовать.
Отформатировал флэшку под NTFS. Думал, выну ее из разъема после эксперимента, и все будет в порядке. Как бы не так. После выполения указанной вами команды съемный диск остается, explorer зависает, taskmgr не запускается.
О, спасибо. Думаю, что в намерения авторов расшифровка после оплаты не входит. Наверное, тяжело это сделать, не спалившись. Если бы они расшифровывали файлы, то была бы инструкция, что делать после оплаты.
Обход всего, что есть в аутлуке, сверху вниз.
Исходная модель данных ничего о визиторах не знает, поэтому вокруг ее объектов сделаны обертки с методами accept.
Чтобы не писать много однотипных методов, при помощи reflection сделан один универсальный метод accept.
Visitor работает с отдельными элементами, содержимое каталога извлекает FolderElement.
Основная идея данного приема — избавиться от god-метода со свитчом:
Если figure — простая фигура, то этот switch можно расширять до бесконечности и особых проблем не заметить. Но если figure состоит из других фигур, то внутри методов visitRectangle, visitCircle, visitTriangle придется сделать отдельные свитчи, и вот тут-то уже возникают реальные сложности, когда можно в 3 объектах запутаться. И тогда на помощь приходит Visitor.
В некоторых случаях это может быть очень важно. Например, есть такая штука как SSIS-пакеты, в них практически невозможно изменения сматчить с дефектами, потому что там файлы почти бинарные. И разумеется, разработчики, когда их начинали писать, читали интересные статьи о том, какая это классная штука.
В части багтрекинга мне было бы достаточно, если бы в багтрекере была подсветка синаксиса, а в IDE работали бы ссылки из комментариев вида // Also see Issue 166;.
По-моему, после нескольких лет серьезной разработки становится все равно, на каком языке писать. Если у меня долгоиграющий проект, то я буду его продолжать на том языке, на котором написана большая часть кода, хоть на дельфи.
Если у меня новый проект, то я буду смотреть на:
и где-то там, пунктов на 10 ниже, будет синтаксис.
Поэтому описание особенностей синтаксиса не отвечает на вопрос из заголовка: «Почему следует полностью переходить на Kotlin».
Не очень понял про кэширующий сервер на Windows. Как вы представляете атаку на него? Или вы имеете в виду случай, когда NTFS-раздел примонтирован к каталогу?