Как сделать сигнатуру

Добавил пользователь Alex
Обновлено: 05.10.2024

В этой статье мы более подробно продолжим обсуждение значений заголовков IP-протокола, используя примеры конкретных сигнатур. Хотя относительно легко создать сигнатуру, соответствующую специфическому типу трафика, гораздо труднее учесть в ней минимальное количество ложных сигналов тревоги и не отфильтрованных вредных пакетов. Все сигнатуры должны быть тщательно проверены и доработаны, чтобы создать высокоточные и эффективные подписи.

Оценка эффективности сигнатуры

В предыдущей статье мы рассмотрели характеристики пакетов, посланных инструментом synscan (как это осуществлено в черве Ramen) и идентифицировали черты, которые были необычны или подозрительны, или нарушают существующие стандарты. Тогда же мы попробовали определить, какие из этих характеристик годятся для создания хорошей сигнатуры. Теперь, основываясь на этих характеристиках, давайте создадим сигнатуру, которая будет искать все три следующие признака в каждом TCP пакете:

Только набор SYN и FIN флагов
IP identification number 39426
TCP window size 1028

Первая характеристика является слишком общей, чтобы использоваться отдельно для идентификации деятельности synscan. Даже притом, что вторые и третьи характеристики могут, хоть и редко, встречаться в законном трафике, вероятность сочетания обеих этих характеристик в одном и том же пакете крайне мала, так что разумно использовать их наряду с SYN и FIN флагами, чтобы создать точную, детальную сигнатуру. Добавление других признаков synscan кардинально не улучшило бы точность этой сигнатуры, но увеличило бы количество ресурсов, задействованных для идентификации.

Теперь, казалось бы, объединение этих трех характеристик даст сильную и надежную сигнатуру для инструмента synscan. Но это не совсем так. Они, действительно, составляют неплохую сигнатуру, но только для одной специфической версии synscan. Однако существует множество версий synscan, и, очень вероятно, что они имеют различные характеристики заголовков.

Теперь перед нами стоит гораздо более интересная задача – как развить сигнатуру для обнаружения всех вариантов инструмента synscan, то есть для блокирования не только конкретной версии червя Ramen, но и всех его модификаций и аналогов. Требуется создать набор сигнатур, который мог бы обнаруживать не только известные типы атак, но также и будущие и неизвестные варианты такой атаки. Исследуем эту концепцию более подробно.

Добавление данных к сигнатуре

Вместо флагов SYN и FIN, был установлен только флаг SYN. Это - нормальная характеристика TCP пакета
TCP window size был всегда 40, а не 1028. 40 - необычно маленький размер окна для начального SYN пакета и, конечно, гораздо менее вероятен в нормальном пакете, чем 1028.
Reflexive port number был 53, а не 21. Старые версии BIND, действительно, использовали рефлексивные порты для некоторых операций, но более новые версии BIND этого не делают, так что вряд ли можно сейчас часто встретить рефлексивный порт TCP, да еще и именно 53.

TCP пакеты с ненулевым acknowledgement number, но флаг подтверждения не установлен.
TCP пакеты только с SYN и FIN флагами
TCP пакеты с изначально установленным TCP window size ниже, некоторого определенного значения (которое включило бы и 40)

Идентификация аналогичного трафика

Через несколько недель после появления второй версии червя, использовавшего другой вариант synscan, стали появляться пакеты с практически теми же самыми характеристиками. Фактически, единственным, но зато крайне важным отличием было то, что IP identification number больше не был статическим. Самое вероятное объяснение этого - эта третья группа пакетов была создана новым вариантом synscan. Похоже, кто-то взял часть программного кода synscan и создал на основе него новый инструмент, в котором больше не будет статичного IP identification number. Это маскирует деятельность synscan под обычный трафик, делая ее более тайной с точки зрения систем обнаружения вторжения, так как устраняется одна из основных характеристик, по которой защитные системы IDS определяли вторжение.

Здесь стоит заметить следующее: если бы до этого не было двух других, более характерных версий червя, то ущерб от этой третьей волны мог бы быть гораздо большим, чем тот, который в результате суммарно получился от всех трех модификаций вируса. А так мир встретил эту новую угрозу уже практически во всеоружии. Наши сигнатуры, хотя и не будут по отдельности пресекать этот трафик, так как ни один из трех компонентов первоначальной подписи не присутствует в этом варианте пакетов, все еще идентифицируют его, как аномальный и подозрительный при помощи большего количества общих сигнатур. Это показывает большую надежность использования общих сигнатур, которые ищут аномалии в трафике, а не специализируются на специфических сигнатурах, соответствующих конкретным нападениям или эксплоитам.

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

Примечания относительно значений заголовков

IP-адреса (particularly reserved, non-routable, broadcast addresses)
Port numbers, которые не должны быть использованы (особенно всем хорошо известные порты для специфических протоколов и троянов)
Необычная фрагментация пакетов
Специфические комбинации TCP флагов
Типы/коды ICMP, которые обычно не наблюдаются

Есть еще одна проблема, которую мы не рассмотрели – какие пакеты стоит проверять. Если мы используем сигнатуру, основанную на значениях заголовков, то мы должны определить, какие пакеты стоит проверять - все или только некоторые? От этого много зависит. Пакеты ICMP и UDP – пакеты без установления соединения, имеет смысл проверять все из них. А TCP пакеты – пакеты на основе соединения, иногда достаточно проверять только первый пакет. Например, некоторые характеристики типа адресов и портов останутся постоянными во всех пакетах, так нет смысла проверять их несколько раз. Другие характеристики - типа TCP флагов, необходимо проверять в каждом пакете сессии, если мы ищем специфические комбинации флагов. Очевидно, чем большее количество пакетов мы проверяем, тем большее количество времени и ресурсов будет на это затрачено.

Можно задаваться вопросом - почему мы сосредоточились на значениях IP, TCP, UDP и ICMP заголовков, и не упомянули другие, типа DNS. Причина имеет отношение к методу структурирования пакетов. Помните, что TCP, UDP и ICMP - все это IP протоколы, так что их заголовки и содержимое расположены внутри IP-пакетов. Чтобы получать данные TCP заголовка, например, мы сначала нуждаемся в разборе IP заголовка, так что мы можем определить его содержимое. Другие протоколы, такие как DNS, содержатся внутри UDP и TCP содержимого пакетов, так что нам требуется пройти два уровня разбора (IP и UDP или TCP) чтобы добраться до них. Требуется гораздо больший объем программной работы, чтобы декодировать многие из этих протоколов, по сравнению с относительно простой структурой заголовков TCP, UDP и ICMP. Мы рассмотрим это более подробно в следующих статьях по данной теме.

В нашем телеграм канале мы рассказываем о главных новостях из мира IT, актуальных угрозах и событиях, которые оказывают влияние на обороноспособность стран, бизнес глобальных корпораций и безопасность пользователей по всему миру. Узнай первым как выжить в цифровом кошмаре!

Краткий обзор

Стоит отметить, что пока доступна только альфа-версия BASS и многое еще предстоит доработать. У этого проекта открытый исходный код, и мы активно работаем над ним, поэтому будем рады любым отзывам сообщества и рекомендациям по его улучшению. Исходный код BASS доступен здесь.

Проект BASS был анонсирован в 2017 году на конференции REcon в Монреале, Канада.

Актуальность

Специалисты Talos ежедневно получают более 1,5 млн уникальных образцов. В большинстве своем они относятся к известным угрозам и сразу же отсеиваются сканером вредоносного ПО (ClamAV). Однако после сканирования остается немало файлов, которые все же нуждаются в дальнейшем анализе. Мы запускаем их в песочнице и проводим динамический анализ, позволяющий разделить их на вредоносные и безопасные. Отобранные на этом этапе вредоносные образцы мы обрабатываем, чтобы на их основе создать сигнатуры ClamAV, которые помогут в дальнейшем отфильтровывать эти угрозы на более раннем этапе, во время сканирования.

За три месяца, с февраля по апрель 2017 года, базу данных ClamAV пополнили 560 000 новых сигнатур, то есть прирост составлял 9500 сигнатур в день. Значительную часть из них мы получили автоматически в виде хэш-сигнатур. У таких сигнатур есть один существенный недостаток по сравнению с сигнатурами на основе шаблонов или байт-кода (это два других типа, поддерживаемых ядром ClamAV): одна хэш-сигнатура соответствует только одному файлу. Кроме того, рост числа хэш-сигнатур приводит к тому, что база ClamAV занимает больше памяти. Именно поэтому мы предпочитаем сигнатуры на основе шаблонов. Ими гораздо проще и быстрее управлять, чем байт-кодовыми, и в то же время они позволяют описывать целые кластеры файлов.

Фреймворк BASS призван облегчить создание сигнатур ClamAV на основе шаблонов. Он автоматически генерирует их, обрабатывая сегменты двоичного исполняемого кода.

BASS берет за основу кластеры вредоносного кода, но не включает средства их создания. За счет этого технология остается удобной и гибкой. Мы намеренно сделали входной интерфейс универсальным, чтобы его легко было адаптировать к новым источникам кластеров. Сейчас мы используем несколько таких источников, в том числе кластеры на основе индикаторов компрометации (IoC) из нашей песочницы, структурное хэширование (когда у нас есть заведомо вредоносный исполняемый файл и мы ищем дополнительные образцы, схожие с ним по структуре) и вредоносное ПО, полученное из спам-кампаний.

На первом этапе вредоносные экземпляры проходят через распаковщики ядра ClamAV. Оно может распаковывать архивы различных форматов и сжатые исполняемые файлы (например, UPX), а также извлекать встроенные объекты (такие как файлы EXE внутри документов Word). Полученные артефакты тщательно анализируются, идет сбор информации. Сейчас для следующего этапа, фильтрации, мы используем их размеры и магическую строку UNIX.

Затем кластер вредоносного кода проходит фильтрацию. Если файлы не соответствуют требованиям BASS (пока платформа работает только с исполняемыми файлами PE, но не составит труда добавить поддержку двоичных файлов ELF и MACH-O), они удаляются из кластера либо, если объектов осталось слишком мало, кластер забраковывается полностью.

Отфильтрованный кластер переходит на этап генерации сигнатур. Сначала производится дизассемблирование двоичных файлов. Для этого мы используем IDA Pro, но его можно без проблем заменить на другой дизассемблер со схожими возможностями, например на radare2.

После дизассемблирования необходимо выявить в образцах общий код, чтобы на его основе сгенерировать сигнатуры. Этот шаг важен по двум причинам. Во-первых, алгоритм создания сигнатур требует значительных вычислительных ресурсов и лучше работает с короткими сегментами кода. Во-вторых, предпочтительнее получать сигнатуры из образцов кода, которые схожи не только синтаксически, но и семантически. Для сравнения кода мы используем утилиту BinDiff. Опять же, ее тоже легко заменить, и в будущем мы, возможно, интегрируем в фреймворк другие утилиты для сравнения.

Если кластер небольшой, BinDiff сравнивает каждый исполняемый файл со всеми остальными. В противном случае охват сравнения сокращается, иначе процесс может слишком затянуться. На основе полученных результатов строится граф, где вершины обозначают функции, а ребра — их схожесть. Чтобы найти хорошую общую функцию, достаточно найти связный подграф с высоким общим показателем схожести.

Подграф ƒ1, ƒ2, ƒ4, ƒ6 с высокими показателями схожести вершин (см. рисунок выше) — отличный кандидат на роль общей функции.

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

Тогда и начинается непосредственно генерация сигнатуры. Сигнатуры ClamAV на основе шаблонов призваны выявлять подпоследовательности в двоичных данных. Поэтому мы применяем ко всем извлеченным функциям алгоритм поиска наибольшей общей для них подпоследовательности (LCS, Longest Common Subsequence).

C вычислительной точки зрения этот алгоритм достаточно затратен даже для двух образцов и заметно тяжелее для нескольких, поэтому мы применяем его эвристическую разновидность, описанную Кристианом Бличманом (Christian Blichmann). Результат может выглядеть примерно так:

Наконец, перед публикацией сигнатуры ее нужно протестировать. Мы автоматически проверяем сигнатуру с помощью нашего набора тестов на ложноположительные срабатывания. Для большей достоверности мы применяем Sigalyzer — новую возможность нашего подключаемого модуля CASC IDA Pro ClamAV для генерации и анализа сигнатур (он будет обновлен позднее). Sigalyzer помечает участки двоичного файла, которые совпали с сигнатурой ClamAV, сработавшей для него. Таким образом формируется наглядное визуальное представление сигнатуры.

Архитектура

BASS реализован в виде кластера контейнеров Docker. Фреймворк написан на Python и взаимодействует со всеми необходимыми инструментами через веб-сервисы. Архитектура создана по аналогии с проектом VxClass, который также генерировал сигнатуры ClamAV с помощью IDA Pro и BinDiff, но впоследствии бы закрыт и, в отличие от BASS, недоступен широкой публике.

Ограничения

BASS работает исключительно с двоичными исполняемыми файлами, поскольку сигнатура генерируется из кода образца. Кроме того, он анализирует только исполняемые файлы x86 и x86_64. Поддержка других архитектур может появиться в будущем.

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

И еще раз хотим напомнить, что BASS находится на стадии альфа-тестирования, и пока не все работает гладко. Но мы надеемся, что принесем пользу сообществу, развивая этот фреймворк как проект с открытым исходным кодом, и будем рады любым идеям и критике.

Приложение

Разница между наибольшей общей подстрокой и наибольшей общей подпоследовательностью

На следующей иллюстрации показана разница между наибольшей общей подстрокой и наибольшей общей подпоследовательностью. Наибольшая общая подпоследовательность обозначена в нашей публикации английской аббревиатурой LCS.

На этом все. А уже 20 июня можно будет подробно ознакомиться с программой курса на дне открытых дверей, который пройдет в режиме вебинара.

Зачем она нужна?

Подпись в почте важна для построения отношений с подписчиками, для формирования доверия и положительного имиджа компании.

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

Кроме того, подготовив заранее подпись в электронное письмо, вы не будете лишний раз задумываться над тем, как его закончить и оформить.

Виды подписей

Подписи в письмах могут понадобиться людям и компаниям с абсолютно разными сферами деятельности. Их вид и контент тоже будет отличаться. Подписи в электронных письмах можно разделить на такие категории:

Профессиональные. Профессионалы и эксперты в разных сферах бизнеса указывают в подписи имя, должность и контактную информацию, а также добавляют фото. Можно сказать, что это самый распространенный вид подписи.

Корпоративные. Его широко используют в рассылках магазины, агентства недвижимости, юридические компании, образовательные центры и т.д. Когда вся коммуникация ведётся не от лица одного человека, а от команды.

Креативные и оригинальные. Например, вместо традиционной фотографии может быть забавная рожица:

Лаконичные. В примере ниже - только автограф автора, его имя и должность:

Неформальные. Вот пример такой подписи в почте (контент письма с юмором, и подпись соответствующая):

Чего стоит избегать при составлении подписи

Слишком длинного перечня ваших аккаунтов из соцсетей (имеет смысл указать основные). Вот пример из реальной подписи:

Дублирования емейл адреса (получатель рассылки уже видел, от кого пришло письмо, а если в поле “отправитель” все-таки указан другой адрес, это веский повод внести корректировки в шаблоны ваших писем).

Составляем крутую подпись

Что можно включить в подпись:

должность (если письмо отправляется от имени конкретного человека);

дополнительную контактную информацию - телефон и адрес сайта.

Если оформить все сведения об отправителе в единый блок с помощью специальных сервисов и создать подпись в стиле сайта - так вы точно заставите своих адресатов обратить внимание на ваше послание и запомнить вас!

Программа минимум - просто не забыть добавить подпись в свое письмо. В Gmail это можно сделать в разделе “Настройки”:

Этот сервис позволяет создать как индивидуальную подпись, так и серию подписей в одном стиле для группы сотрудников. Последняя опция доступна в бизнес версии этого приложения. Есть бесплатный двухнедельный тестовый период, на протяжении которого можно испытать все функциональные возможности данного сервиса.

Личную же подпись здесь можно сделать бесплатно, чем мы сейчас и займемся:

На первом шаге пользователю предлагается указать сферу своей деятельности, от этого будет зависеть стиль подписи:

Далее открывается форма для заполнения полей и загрузки фото пользователя или логотипа компании. Не обязательно вписывать данные во все поля: указывайте только ту информацию, которую вы хотите донести до своих адресатов.

Заполнив контактную информацию и добавив ссылки на аккаунты соцсетей, получаем подпись выбранного формата:

В платной версии есть возможность редактирования размера и цвета шрифта, а также параметры иконок соцсетей.

Полученную подпись можем использовать для своего почтовика (ее можно просто скопировать и вставить в настройках своего почтовика):

А можно процедуру сохранения и синхронизации до конца и она появится автоматически в шаблоне письма.

На этапе сохранения подписи нужно выбрать свой почтовик, для некоторых из них или для получения ее HTML-версии нужен PRO аккаунт:

Подпись почти готова, осталось войти в свой аккаунт:

После этого подпись будет добавлена в ваши письма:

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

Сохраняем изменения и получаем подпись в выбранном формате:

Для создания email signature есть и другие приложения, вот некоторые из них: New Old Stamp, HTMLsig, Hubspot Signature Generator.

Как сделать подпись для email-рассылок в eSputnik

Создать подпись для HTML письма не составит труда в нашем редакторе.

Вариант 1: подпись в 2 колонки

Если нужно дополнить футер письма, может подойти подпись такого вида:

Чтобы ее сделать, мы подготовили картинку для подписи (в данном случае - фото сотрудника компании):

Вставили в один блок фото, в другой - текст.

Затем отредактировали шрифты для подписи, чтобы они соответствовали дизайну электронного письма

Вариант 2: подпись в 3 колонки

Этот вариант отличается только использованием структуры с тремя блоками. Получим следующую подпись электронного письма:

Креативные идеи для подписи

Можно немного покреативить и сделать разные варианты подписи в конце письма. Для этого может быть достаточно добавить тематические элементы к фото представителя компании. Вот как эту идею реализовали наши клиенты, сделав подписи на все случаи жизни: стандартную, новогоднюю, к 8 марта и Дню святого Патрика

Креативные подписи в новом редакторе

Правила оформления письма и подписи

Теперь вы знаете почти все о том, как подписывать письмо. Единых стандартов обращения в письме нет, есть только общепринятые нормы:

Составляя подпись, принимайте во внимание особенности вашей компании и аудитории, с которой предстоит коммуницировать, делая рассылки писем. А также оформление делового письма может отличатся от информационного, триггерного или промо.

Разные категории писем одной и той же компании могут иметь разных отправителей и абсолютно разные подписи. Например, в футере проморассылок - фото и контактные данные менеджера по работе с клиентами, триггера с запросом отзыва отправляются от имени коммерческого директора с его контактным телефоном.

Email-подпись, пусть и не всегда самая заметная часть футера, может в значительной мере повлиять на продвижение компании и ее имидж, а также на вашу профессиональную репутацию.

Поэтому важно уделить достаточно сил и времени ее созданию. Для этого можно воспользоваться функционалом адаптивного редактора еСпутник при подготовке html шаблонов писем или специальными приложениями для тех случаев, когда вам нужно сформировать оригинальную подпись для писем, отправляемых партнерам и клиентам через почтовики.

Привет! Ты уже освоил создание собственных классов, с полями и методами. Сегодня мы как раз подробно поговорим про методы. Мы, конечно, уже не раз делали это в наших лекциях, но мы говорили в основном об общих моментах. Сегодня же мы буквально разберем методы “по частям” — узнаем из чего они состоят, какие варианты их создания существуют и как всем этим можно управлять:) Поехали!

Сигнатура метода

Весь код, который описывает метод, называется объявлением метода . Сигнатура метода включает название метода и типы параметров в определенном порядке. Общий вид объявления можно описать так: Рассмотрим для примера объявлений нескольких методов класса Dog .

1. Модификатор доступа

Модификатор доступа всегда указывается первым. Все методы класса Dog обозначены модификатором public . То есть мы можем вызвать их из любого другого класса: Методы класса Dog , как видишь, легко доступны в классе Main . Это возможно именно благодаря модификатору public . В Java есть и другие модификаторы, и не все из них позволят использовать метод внутри другого класса. О них мы поговорим в других лекциях. Главное, запомни за что отвечает модификатор: за доступность/недоступность метода в других классах:)

2. Ключевое слово static

Один из методов Dog , а именно main() обозначен ключевым словом static . Если же оно есть — то указать его необходимо после модификатора доступа. Помнишь, в прошлых лекциях мы говорили о статических переменных класса? Применительно к методам это слово имеет примерно тот же смысл. Если метод указан как static — это означает, что он может использоваться без ссылки на конкретный объект класса. И действительно — чтобы запустить статический метод main() в классе Dog тебе не нужно создавать экземпляр Dog , он запускается и без этого. Если бы этот метод не был статическим — то для его использования нам понадобилось бы сперва создать объект.

3. Возвращаемое значение.

Если наш метод должен что-то вернуть, то далее мы указываем тип возвращаемого значения. Это видно на примере геттера getName() : Он возвращает объект типа String . Если же метод ничего не возвращает — вместо типа указывается ключевое слово void , как в методе woof() :

Методы с одинаковыми именами

Бывают ситуации, когда в нашей программе нужно несколько вариантов работы метода. Почему бы нам не создать свой собственный искусственный интеллект? У Amazon есть Alexa, у Яндекса — Алиса, так чем мы хуже?:) В фильме про Железного Человека Тони Старк создал собственный выдающийся искусственный интеллект — J.A.R.V.I.S. Отдадим должное прекрасному персонажу и назовем наш ИИ в его честь:) Первое, чему мы должны научить Джарвиса — здороваться с людьми, которые заходят в комнату (будет странно, если столь великий интеллект окажется невежливым). Вывод в консоль: Отлично! Джарвис умеет приветствовать вошедшего. Чаще всего, конечно, это будет его хозяин — Тони Старк. Но ведь он может прийти не один! А наш метод sayHi() принимает на вход только один аргумент. И, соответственно, сможет поприветствовать только одного из пришедших, а другого проигнорирует. Не очень-то вежливо, согласен?:/ В этом случае чтобы решить проблему мы можем просто написать в классе 2 метода с одинаковым названием, но с разными параметрами: Это называется перегрузкой методов . Перегрузка позволяет нашей программе быть более гибкой и учитывать различные варианты работы. Проверим как это работает: Вывод в консоль: Отлично, оба варианта сработали:) Тем не менее, проблему мы не решили! Что, если гостей будет трое? Конечно, мы можем еще раз перегрузить метод sayHi() , чтобы он принимал имена трех гостей. Но их ведь может быть и 4, и 5. И так до бесконечности. Нет ли другого способа научить Джарвиса работать с любым количеством имен, без миллиона перегрузок метода sayHi() ? :/ Конечно, есть! Иначе была бы разве Java самым популярным в мире языком программирования? ;) Запись ( String. names ) переданная в качестве параметра позволяет нам указать, что в метод передается какое-то количество строк. Мы не оговариваем заранее сколько их должно быть, поэтому работа нашего метода становится теперь намного более гибкой: Вывод в консоль: Внутри метода мы в цикле перебираем все аргументы и выводим готовые фразы с именами на консоль. Здесь мы применяем упрощенный цикл for-each (ты уже с ним сталкивался). Он отлично подходит, потому что запись String. names — на самом деле означает, что все переданные параметры помещаются компилятором в массив. Поэтому с переменной names можно работать как с массивом, в том числе — перебирать в цикле. При этом он сработает при любом количестве переданных строк! Две, десять, хоть тысяча — метод будет стабильно работать с любым количеством гостей. Намного удобнее, чем делать перегрузки для всех возможных вариантов, согласен?:) Приведем еще один пример перегрузки метода. Добавим Джарвису метод printInfoFromDatabase() . Он будет печатать в консоль информацию о человеке из базы данных. Если в базе данных указано, что человек является супергероем или суперзлодеем — эта информация также будет выведена на экран: Вывод: Вот так, наш метод работает в зависимости от данных которые мы в него передаем. Еще один важный момент: порядок следования аргументов имеет значение! Допустим, наш метод принимает на вход строку и число: Если метод sayYourAge() класса Man принимает на вход строку и число — значит именно в таком порядке их нужно передавать в программе! Если мы передадим их в другом порядке — компилятор выдаст ошибку и человек не сможет назвать свой возраст. Кстати, конструкторы, которые мы проходили в прошлой лекции, тоже являются методами! Их тоже можно перегружать (создавать несколько конструкторов с разным набором аргументов) и для них тоже принципиально важен порядок передачи аргументов. Настоящие методы!:)

Как вызывать методы с похожими параметрами

Как ты знаешь, в Java есть такое слово как null. При работе с ним очень важно понимать, что null не является ни объектом, ни типом данных. Представь себе, что у нас есть класс Man и метод introduce() , который объявляет имя человека и его возраст. При этом возраст можно передать в форме текста, а можно - числом. С перегрузкой мы уже знакомы, поэтому знаем, что метод оба раза отработает как надо: Но что будет, если в качестве второго параметра мы передаем не строку и не число, а null? Мы получим ошибку компиляции! Ошибка “Ambiguous method call” переводится как “двусмысленный вызов метода”. Из-за чего она могла возникнуть и в чем заключается “двусмысленность”? На самом деле все просто. Дело в том, у нас есть два варианта метода: со String и с Integer в качестве второго аргумента. Но и String , и Integer могут быть null! Для обоих типов (поскольку они ссылочные) null является значением по умолчанию. Именно поэтому компилятор в данной ситуации не может разобраться, какой вариант метода он должен вызвать. Решить эту проблему достаточно просто. Дело в том, что null можно явно преобразовать к конкретному ссылочному типу. Поэтому при вызове метода ты можешь указать в скобках нужный тебе тип данных для второго аргумента! Компилятор поймет твой “намек” и вызовет нужный метод: Вывод: А вот если бы числовой параметр был примитивом int , а не объектом ссылочного типа Integer — такой ошибки не возникло бы. Догадался почему? Если догадался — молодец:) Потому что примитивы не могут быть равны null. Теперь у компилятора остался только один вариант вызова метода introduce() — с двумя строками. Именно этот вариант метода и будет отрабатывать каждый раз при вызове метода.

Читайте также: