Если у есть объекты, которые вам по сути не нужны (за исключением их методов, раз уж они stateless), то заведите себе статический util класс с этими методами.
Синглтон если уж и делать, то как раз для stateful объекта, чтобы везде был доступен один и тот же объект с одним и тем же состоянием.
Спасибо за статью! Как программисту, очень далекому от UX-проектирования, было очень интересно.
Хорошо, если есть аудитория, на которой можно протестировать какие-то свои UX-решения, которые показались удачными, и понять, верно ли показалось или нет. Но если такой аудитории нет, есть ли способы как-то проанализировать свои решения и понять, хорошие они или нет? Есть ли какое-нибудь золотое правило UX-проектирования?
Про улучшение производительности в HashMap при большом количестве коллизий не знал, спасибо! Оказывается, относительно давно оно произошло. А где именно у нас говорится про худшее время операции? Бегло просмотрев лекцию по коллекциям, не нашел.
Не упоминать об этом было нельзя, т.к. у студентов уже был курс алгоритмов и структур данных, так что устройство HashMap они должны понимать на довольно глубоком уровне. Как и TreeMap.
Да, примеры «как делать не надо» хорошие. Я бы даже эту фразу сделал жирной :)
Особенность DCL-паттерна в том, что момент публикации объекта — это операция volatile-записи, а не выход из секции синхронизации. Поэтому именно volatile-запись должна производиться после полной инициализации объекта.
Хорошая статья, спасибо! Про потоки стоит еще добавить важное замечание, что все промежуточные операции над потоками — ленивые. Т.е. они не будут выполнены пока не вызвана терминальная операция.
Сейчас телефоны и почие девайсы, требующие доступ к гугл-аккаунту, авторизуются через какие-то уникальные пароли, которые не совпадают с паролем от учетной записи гугла. Возможно, при смене основного пароля старые пароли для приложений продолжают работать.
П.с. всегда приятно почитать статью с хеппи-ендом :)
Еще забавно, что описаны 2 состояния собаки: покой и агрессия. Но при этом встречаются изображения (в том числе и на видео), где она в боевом режиме в состоянии покоя.
И там уже (как я очень надеюсь) можно использовать любой сериализатор.
Синглтон если уж и делать, то как раз для stateful объекта, чтобы везде был доступен один и тот же объект с одним и тем же состоянием.
Хорошо, если есть аудитория, на которой можно протестировать какие-то свои UX-решения, которые показались удачными, и понять, верно ли показалось или нет. Но если такой аудитории нет, есть ли способы как-то проанализировать свои решения и понять, хорошие они или нет? Есть ли какое-нибудь золотое правило UX-проектирования?
Не упоминать об этом было нельзя, т.к. у студентов уже был курс алгоритмов и структур данных, так что устройство HashMap они должны понимать на довольно глубоком уровне. Как и TreeMap.
Сохранение профилей водетелей — это круто
Если аннотацию @ Override убрать, код тоже останется корректным, однако она сильно упрощает жизнь. Тут, видимо, аналогичная ситуация.
П.с. всегда приятно почитать статью с хеппи-ендом :)