Забавно, но я считаю, наоборот, самый приостым и универсальным решением инъекцию через поля. Конструктор всегда должне быть пустой. Плюсы следующие: 1. Наследование. В конструкторе унаследованного класса не надо перечислять поля родителя. 2. Возможность иметь циклические зависимости. Кто-то скажет, что это антипаттерн. Может быть. Но лучше иметь такую возможность. 3. Когда зависимостей много, конструктор со всеми зависимостями становится совершенно нечитаемым. Если разнести по полям, читабельность улучшается. 4. Возможность задать значения по-умолчанию с аннотацией @Autowired(optional=true) 5. Лучше безобразно но единообразно. Всегда пустой конструктор и инъекция через поля - не надо думать, какие поля вынести в конструктор (всегда никакие)
И, в довесок, поля должны быть package private. Это во-первых, меньше букв. Во-втрорых, при написании тестов такие поля очень просто инициализировать.
Если писать мега крутую игру с большим бюджетом типа CoD или BF, наверное, есть смысл использовать UDP и реализовывать на нем нужные фишки TCP. Но если проект с небольшим бюджетом, то немногим более высокий пинг это последнее о чем стоит беспокоиться.
Аналогия велосипеда и программного совершенно не корректна. Да железная рама должна быть прочной из единого куска алюминия. Но программный код не должен быть монолитным чтобы быть надежным
Хотелось бы более углубленной проработки темы. В JavaFX есть такая интересная штука как Preloader. Запустить или собрать прогу с ним уже более интересная задача.
Почему то все забывают, что ламбды то нам обещают в 8-ка, а вот полноценных замыканий нет. Сейчас изнутри лямбды (как и безымянного вложенного класса) можно обращаться только к финальным локальным переменным метода в котором они создаются. Как это не поразительно в 8-ке на собираются менять этот ужас. Даже в JavaScript замыкания реализованы, а в Java нет.
Очень надеюсь, что в StarCraft II никогда не будут ничего продавать, даже портреты и наряды. Иначе брошу, как бросил DoT'а где достали сундучками с выклянчиванием денег за ключи.
Лучше бы исправили ошибки, которых в Unity сейчас ТОННЫ и, заодно, систему патчей ввели, чтобы не надо было выкачивать весь дистрибутив да еще и с демо-проектом.
Я как-то написал небольшую библиотечку, облегчающую обработку checked exceptions. Достаточно просто обернуть лямбду в
StreamUtil.uncheckedhttps://github.com/Megaprog/stream-util/blob/master/src/main/java/org/jmmo/util/StreamUtil.java#L184Забавно, но я считаю, наоборот, самый приостым и универсальным решением инъекцию через поля. Конструктор всегда должне быть пустой. Плюсы следующие:
1. Наследование. В конструкторе унаследованного класса не надо перечислять поля родителя.
2. Возможность иметь циклические зависимости. Кто-то скажет, что это антипаттерн. Может быть. Но лучше иметь такую возможность.
3. Когда зависимостей много, конструктор со всеми зависимостями становится совершенно нечитаемым. Если разнести по полям, читабельность улучшается.
4. Возможность задать значения по-умолчанию с аннотацией
@Autowired(optional=true)5. Лучше безобразно но единообразно. Всегда пустой конструктор и инъекция через поля - не надо думать, какие поля вынести в конструктор (всегда никакие)
И, в довесок, поля должны быть package private. Это во-первых, меньше букв. Во-втрорых, при написании тестов такие поля очень просто инициализировать.